From adrian at freebsd.org  Mon May 18 08:06:14 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 18 08:06:20 2009
Subject: FreeBSD-Xen Current updates
Message-ID: <d763ac660905180043g60fe2bf2oe52083d47e5a2e7c@mail.gmail.com>

G'day everyone,

I've been toying around with FreeBSD-Current and Xen over the last few days.

I've quitened a niggling debug statement in the console code that
printed something every time a character was read in the debugger. If
a developer would like it re-enabled they can do it themselves; it was
making my ddb sessions almost impossible to do. :)

Kip had committed a fix to the netfront code a few months ago which
was then accidentally undone by dfr. I've re-committed the fix to
-head and this allows my Xen DomU to finish booting and start running.

I've noticed that buildworlds seem to fail because of weird time
related issues. Has anyone else seen some weird clock behaviour?

Thats about it for now!



Adrian
From adrian at freebsd.org  Mon May 18 12:53:38 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 18 12:53:44 2009
Subject: My FreeBSD-current/Xen install notes
Message-ID: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>

I've started documenting (mostly for my own memory for now!) my
experiences getting a working FreeBSD-current Xen environment
together.

http://wiki.freebsd.org/AdrianChadd/XenHackery

Notable bits: pygrub works. :)



Adrian
From js at alien8.de  Mon May 18 15:59:40 2009
From: js at alien8.de (Julian Stecklina)
Date: Mon May 18 15:59:46 2009
Subject: FreeBSD-Xen Current updates
References: <d763ac660905180043g60fe2bf2oe52083d47e5a2e7c@mail.gmail.com>
Message-ID: <877i0ez9k3.fsf@tabernacle.lan>

Adrian Chadd <adrian@freebsd.org> writes:

> G'day everyone,
>
> I've been toying around with FreeBSD-Current and Xen over the last few days.
>
> I've quitened a niggling debug statement in the console code that
> printed something every time a character was read in the debugger. If
> a developer would like it re-enabled they can do it themselves; it was
> making my ddb sessions almost impossible to do. :)
>
> Kip had committed a fix to the netfront code a few months ago which
> was then accidentally undone by dfr. I've re-committed the fix to
> -head and this allows my Xen DomU to finish booting and start running.
>
> I've noticed that buildworlds seem to fail because of weird time
> related issues. Has anyone else seen some weird clock behaviour?

Yes (after some minutes the clock jumps to some constant point in the
past). But I have no Xen test box at the moment to verify that. :-/

Regards,
-- 
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

From adrian at freebsd.org  Mon May 18 17:00:34 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 18 17:00:40 2009
Subject: FreeBSD-current/Xen and block device enumeration
Message-ID: <d763ac660905181000o6f0b9bc8l88f976f7126a87cf@mail.gmail.com>

This config:

disk = [
        'phy:/dev/hosting2_data2/XEN_freebsd_root,0x01,w',
        'phy:/dev/hosting2_data2/XEN_freebsd_swap,0x02,w'
        ]


Gives this output in dmesg:

xbd0: 10240MB <Virtual Block Device> at device/vbd/1 on xenbus0
GEOM: new disk xbd0
xbd1: 512MB <Virtual Block Device> at device/vbd/2 on xenbus0
WARNING: WITNESS option enabled, expect reduced performance.
GEOM: new disk xbd0

and then ls -l /dev/xbd* :

freebsd_domu# ls -l /dev/xbd*
crw-r-----  1 root  operator    0,  41 May 18 02:51 /dev/xbd0
crw-r-----  1 root  operator    0,  41 May 18 02:51 /dev/xbd0

Hm, I wonder whats busted!



Adrian
From mister.olli at googlemail.com  Mon May 18 17:36:16 2009
From: mister.olli at googlemail.com (Mister Olli)
Date: Mon May 18 17:36:23 2009
Subject: [Fwd: Re: FreeBSD-current/Xen and block device enumeration]
Message-ID: <1242668158.6255.14.camel@phoenix.blechhirn.net>

-------- Forwarded Message --------
> From: Mister Olli <mister.olli@googlemail.com>
> Reply-to: mister.olli@googlemail.com
> To: Adrian Chadd <adrian@freebsd.org>
> Subject: Re: FreeBSD-current/Xen and block device enumeration
> Date: Mon, 18 May 2009 19:07:16 +0200
> 
> hi,
> 
> I had a similar setup with up to 4 block devices connected to a domU,
> but my config looked a little bit different. Instead of 0x01/0x02/...
> I've used hda/hdb/... and it worked quite well.
> 
> Btw, I've never seen a 0x.. configuration before ;-))
> 
> Regards,
> ---
> Mr. Olli
> 
> On Tue, 2009-05-19 at 01:00 +0800, Adrian Chadd wrote:
> > This config:
> > 
> > disk = [
> >         'phy:/dev/hosting2_data2/XEN_freebsd_root,0x01,w',
> >         'phy:/dev/hosting2_data2/XEN_freebsd_swap,0x02,w'
> >         ]
> > 
> > 
> > Gives this output in dmesg:
> > 
> > xbd0: 10240MB <Virtual Block Device> at device/vbd/1 on xenbus0
> > GEOM: new disk xbd0
> > xbd1: 512MB <Virtual Block Device> at device/vbd/2 on xenbus0
> > WARNING: WITNESS option enabled, expect reduced performance.
> > GEOM: new disk xbd0
> > 
> > and then ls -l /dev/xbd* :
> > 
> > freebsd_domu# ls -l /dev/xbd*
> > crw-r-----  1 root  operator    0,  41 May 18 02:51 /dev/xbd0
> > crw-r-----  1 root  operator    0,  41 May 18 02:51 /dev/xbd0
> > 
> > Hm, I wonder whats busted!
> > 
> > 
> > 
> > Adrian
> > _______________________________________________
> > freebsd-xen@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org"

From adrian at freebsd.org  Mon May 18 19:05:12 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 18 19:05:24 2009
Subject: FreeBSD-current/Xen and block device enumeration
In-Reply-To: <d763ac660905181000o6f0b9bc8l88f976f7126a87cf@mail.gmail.com>
References: <d763ac660905181000o6f0b9bc8l88f976f7126a87cf@mail.gmail.com>
Message-ID: <d763ac660905181205p40c0049fo522449221b3020f3@mail.gmail.com>

(Cross-posting to -current because of the way a badly confused Xen
DomU confuses GEOM and populates invalid stuff.)

2009/5/19 Adrian Chadd <adrian@freebsd.org>:
> This config:
>
> disk = [
> ? ? ? ?'phy:/dev/hosting2_data2/XEN_freebsd_root,0x01,w',
> ? ? ? ?'phy:/dev/hosting2_data2/XEN_freebsd_swap,0x02,w'
> ? ? ? ?]

Confuses some "linux" device unit naming type magic in the blkfront device code.

Anyway. To get xbd0 and xbd1 I need to use 0xCA00 and 0xCA10. The code
matches on major 202 (0xca) and shifts the minor bits right to get
partition ids (which I'm not using here.)

This outlines some sanity checking and debugging which should be
improved a little.

> Gives this output in dmesg:
>
> xbd0: 10240MB <Virtual Block Device> at device/vbd/1 on xenbus0
> GEOM: new disk xbd0
> xbd1: 512MB <Virtual Block Device> at device/vbd/2 on xenbus0
> WARNING: WITNESS option enabled, expect reduced performance.
> GEOM: new disk xbd0

.. since I shouldn't be able to do that.

>
> and then ls -l /dev/xbd* :
>
> freebsd_domu# ls -l /dev/xbd*
> crw-r----- ?1 root ?operator ? ?0, ?41 May 18 02:51 /dev/xbd0
> crw-r----- ?1 root ?operator ? ?0, ?41 May 18 02:51 /dev/xbd0

.. or that.


Adrian
From saifi.khan at twincling.org  Tue May 19 03:02:36 2009
From: saifi.khan at twincling.org (Saifi Khan)
Date: Tue May 19 03:02:42 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0905190807290.887@localhost>

On Mon, 18 May 2009, Adrian Chadd wrote:

> I've started documenting (mostly for my own memory for now!) my
> experiences getting a working FreeBSD-current Xen environment
> together.
> 
> http://wiki.freebsd.org/AdrianChadd/XenHackery
> 
> Notable bits: pygrub works. :)
> 
> Adrian

Hi:

What is the extent of Dom0 support for FreeBSD 8.x with Xen
3.3.x ?

My interest is to run multiple guest OS hosted on a Xen-ified
(aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64
box.

Any pointers or observations ?


thanks
Saifi.
From adrian at freebsd.org  Tue May 19 03:52:37 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue May 19 03:52:43 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <Pine.LNX.4.64.0905190807290.887@localhost>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
Message-ID: <d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>

I don't think there's any support for Dom0 stuff in FreeBSD.

http://wiki.freebsd.org/FreeBSD/Xen has further information about what
is and isn't supported at this time.



Adrian

2009/5/19 Saifi Khan <saifi.khan@twincling.org>:
> On Mon, 18 May 2009, Adrian Chadd wrote:
>
>> I've started documenting (mostly for my own memory for now!) my
>> experiences getting a working FreeBSD-current Xen environment
>> together.
>>
>> http://wiki.freebsd.org/AdrianChadd/XenHackery
>>
>> Notable bits: pygrub works. :)
>>
>> Adrian
>
> Hi:
>
> What is the extent of Dom0 support for FreeBSD 8.x with Xen
> 3.3.x ?
>
> My interest is to run multiple guest OS hosted on a Xen-ified
> (aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64
> box.
>
> Any pointers or observations ?
>
>
> thanks
> Saifi.
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
From saifi.khan at twincling.org  Tue May 19 04:24:16 2009
From: saifi.khan at twincling.org (Saifi Khan)
Date: Tue May 19 04:24:23 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com> 
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0905190944510.1090@localhost>

On Tue, 19 May 2009, Adrian Chadd wrote:

> I don't think there's any support for Dom0 stuff in FreeBSD.
> 
> http://wiki.freebsd.org/FreeBSD/Xen has further information about what
> is and isn't supported at this time.
> 
> Adrian
> 
> 2009/5/19 Saifi Khan <saifi.khan@twincling.org>:
> > On Mon, 18 May 2009, Adrian Chadd wrote:
> >
> >> I've started documenting (mostly for my own memory for now!) my
> >> experiences getting a working FreeBSD-current Xen environment
> >> together.
> >>
> >> http://wiki.freebsd.org/AdrianChadd/XenHackery
> >>
> >> Notable bits: pygrub works. :)
> >>
> >> Adrian
> >
> > Hi:
> >
> > What is the extent of Dom0 support for FreeBSD 8.x with Xen
> > 3.3.x ?
> >
> > My interest is to run multiple guest OS hosted on a Xen-ified
> > (aka paravirtualized) FreeBSD 8.x on a multi-core intel or AMD64
> > box.
> >
> > Any pointers or observations ?
> >

Hi Adrian:

Thank you for the clarification about "no dom0 support in 
FreeBSD 8.x as of now". 

Yes, i did visit the wiki link couple of months ago and in fact
dropped a mail to Kip as well :) there was no response, guess he
was busy.

i'd be thankful, if you could share your observations about the
following:

 . is dom0 support something that FreeBSD will target at some
   point in time or would be happy to be domU ?

 . there was some mention of vimage/bitvisor in one of the
   slides (i think on scribd.com). So, is it that jails getting
   extended to support virtualization+containers and thus a
   entirely different approach which does not use Xen ?

 . is it envisaged that a stable NetBSD dom0 implementation 
   would then be ported to FreeBSD (maybe) ?

Thank you for your time.

thanks
Saifi.
From ivoras at freebsd.org  Tue May 19 09:07:43 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue May 19 09:07:50 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <Pine.LNX.4.64.0905190944510.1090@localhost>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com> 
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com> 
	<Pine.LNX.4.64.0905190944510.1090@localhost>
Message-ID: <9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com>

2009/5/19 Saifi Khan <saifi.khan@twincling.org>:

> ?. is dom0 support something that FreeBSD will target at some
> ? point in time or would be happy to be domU ?

I cannot speak for the developers but at BSDCan it was stated that
dom0 would be a large chunk of job that deserves funding. The
developers are interested.

> ?. there was some mention of vimage/bitvisor in one of the
> ? slides (i think on scribd.com). So, is it that jails getting
> ? extended to support virtualization+containers and thus a
> ? entirely different approach which does not use Xen ?

VIMAGE and jails are OS-level virtualization, orthogonal to Xen.
http://en.wikipedia.org/wiki/Operating_system-level_virtualization

> ?. is it envisaged that a stable NetBSD dom0 implementation
> ? would then be ported to FreeBSD (maybe) ?

Probably not - the systems are too different now.
From adrian at freebsd.org  Tue May 19 13:31:09 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Tue May 19 13:31:16 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <Pine.LNX.4.64.0905190944510.1090@localhost>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
Message-ID: <d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>

2009/5/19 Saifi Khan <saifi.khan@twincling.org>:

> ?. is dom0 support something that FreeBSD will target at some
> ? point in time or would be happy to be domU ?

If Kip (and other Xen-clueful people get funding) - and there's time -
then I bet so.

> ?. there was some mention of vimage/bitvisor in one of the
> ? slides (i think on scribd.com). So, is it that jails getting
> ? extended to support virtualization+containers and thus a
> ? entirely different approach which does not use Xen ?

These solve different problem sets. :)

People seem to think "virtualisation" is "virtualisation". It isn't.
It depends on what kind(s) of problems you're trying to solve. Xen
solves a certain set of virtualisation problems.

> ?. is it envisaged that a stable NetBSD dom0 implementation
> ? would then be ported to FreeBSD (maybe) ?

No idea. Is it stable? :)

Personally, I'd prefer to see the FreeBSD DomU stuff 100% bulletproof
and documented before more stuff is hacked on, but as I said before,
I'm just interested in getting the current pieces into some kind of
documented shape; I'm not hacking on Xen by any stretch of the
imagination!



Adrian
From saifi.khan at twincling.org  Tue May 19 16:25:15 2009
From: saifi.khan at twincling.org (Saifi Khan)
Date: Tue May 19 16:25:27 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0905192149580.6589@localhost>

On Tue, 19 May 2009, Adrian Chadd wrote:

> 
> People seem to think "virtualisation" is "virtualisation". It isn't.
> It depends on what kind(s) of problems you're trying to solve. Xen
> solves a certain set of virtualisation problems.
> 

Could you please share 'your insight' on the 
'set of virtualization problems' that Xen solves ?


thanks
Saifi.
From adrian at freebsd.org  Wed May 20 00:30:11 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed May 20 00:30:18 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <Pine.LNX.4.64.0905192149580.6589@localhost>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
	<Pine.LNX.4.64.0905192149580.6589@localhost>
Message-ID: <d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>

2009/5/20 Saifi Khan <saifi.khan@twincling.org>:

> Could you please share 'your insight' on the
> 'set of virtualization problems' that Xen solves ?

Xen lets you run multiple versions of modified OSes on the same box.
Each OS for the most part can treat its small pool of resources as its
own. It hides the underlying hardware from the virtual domain
(although its apparently quite popular to break out bits of hardware
to appear in the virtual domain.)

The Xen paravirtualisation stuff in -theory- should be more
lightweight than full hardware virtualisation and it should perform
better. In practice? That's very much workload dependant.

Xen also lets you write "other" OSes without needing to care about the
hardware. One of my friends bootstrapped a toy OS of his inside Xen.
He can then run it on any and all Xen boxes, unmodified, regardless of
the underlying hardware. That really hasn't been exploited to its full
potential though.



Adrian
From peterjeremy at optushome.com.au  Fri May 22 00:40:30 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Fri May 22 00:40:43 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
	<Pine.LNX.4.64.0905192149580.6589@localhost>
	<d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>
Message-ID: <20090521215221.GA98253@server.vk2pj.dyndns.org>

On 2009-May-20 08:30:09 +0800, Adrian Chadd <adrian@freebsd.org> wrote:
>Xen also lets you write "other" OSes without needing to care about the
>hardware. One of my friends bootstrapped a toy OS of his inside Xen.
>He can then run it on any and all Xen boxes, unmodified, regardless of
>the underlying hardware. That really hasn't been exploited to its full
>potential though.

This isn't a particularly new idea: The 'CMS' part of IBM VM/CMS was a
hypervisor-aware OS that couldn't run on bare metal.

Relying on the hypervisor for some "traditional" OS services offers
plenty of scope for interesting developments.  One area would be in
University Operating Systems courses - it would again be possible to
offer practical coursework on operating systems that are comprehendable
in their entirety (ala V6 and Minix).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-xen/attachments/20090522/c87105e0/attachment.pgp
From mdc at prgmr.com  Fri May 22 11:37:23 2009
From: mdc at prgmr.com (Michael David Crawford)
Date: Fri May 22 11:37:29 2009
Subject: We'd like to help with Xen
In-Reply-To: <49D6C910.8010409@prgmr.com>
References: <49D6C910.8010409@prgmr.com>
Message-ID: <4A168E71.2090303@prgmr.com>

Michael David Crawford wrote:
> Prgmr.com, Inc. (http://prgmr.com/) is a Xen-based Virtual Private 
> Server hosting service.  We presently offer Linux and NetBSD DomUs, and 
> would like to offer FreeBSD as well.
> 
> I've been asked to help get FreeBSD to work under Xen.  My understanding 
> is that FreeBSD can be gotten to boot as a DomU, but doesn't work reliably.

I just thought I should let you all know that I haven't just 
disappeared, and we are still as committed as we ever were to help with 
Xen on FreeBSD.

However, I've had some trouble getting Xen to work at all on my own 
personal box.

Largely this is because it has a 3ware 9690SA RAID, which is only 
supported in recent Linux kernels, while the production versions of Xen 
all use older kernels.

> I'm an experienced programmer, but not at all with FreeBSD.  The closest 
> I've come to FreeBSD work is the Mac OS X kernel, which is in part based 
> on FreeBSD.  I also used to work with the old BSD-based SunOS, many 
> years ago.

I hadn't done much Linux kernel programming either, so I figured a good 
way to learn would be to backport the 3ware driver.  Such backporting is 
necessary because the Linux kernel's internal API changes with the phase 
of the moon.

O'Reilly's Understanding the Linux Kernel and Linux Device Drivers were 
invaluable, but in the end what I have done is to install the latest 
unstable Xen sources, which work with the latest unstable Linux kernel - 
which includes the (hopefully) stable 3ware driver.

> Other than being eager to help, I don't even know where to start.  Of 
> course I will need to learn FreeBSD kernel programming, but I don't even 
> know where to start with that.

Soon I'll start reading The Design and Implementation of the FreeBSD 
Operating System.  I expect that once I've read just a few chapters I 
can start helping with Xen on FreeBSD in a meaningful way.

I also have a box that boots 8.0-CURRENT natively (not under Xen), so 
that I can learn about FreeBSD kernel and device driver programming 
without the added complexity of running under Xen.

I won't have time to deal with it for a long, long time, but lately I've 
also been toying with the idea of paravirtualizing Haiku.  It's a 
binary-compatible Open Source clone of the BeOS: http://www.haiku-os.org/

So in summary, I don't have any working code for you, and probably won't 
anytime soon, but I am determined to have some eventually.

Mike
-- 
Michael David Crawford
mdc@prgmr.com

    prgmr.com - We Don't Assume You Are Stupid.

       Xen-Powered Virtual Private Servers: http://prgmr.com/xen
From mdc at prgmr.com  Fri May 22 11:41:47 2009
From: mdc at prgmr.com (Michael David Crawford)
Date: Fri May 22 11:42:03 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<9bbcef730905190144w3c0242e0j24434f4924702723@mail.gmail.com>
Message-ID: <4A168ADA.3040505@prgmr.com>


> VIMAGE and jails are OS-level virtualization, orthogonal to Xen.

I want to run Xen so I can build and test Ogg Frog[1] on each of the 
target platforms I plan to support.  I built a fancy Xeon box so that I 
could even build and test on all the platforms simultaneously.

I also operate a couple Internet servers, which are themselves Xen DomUs 
at commercial Xen Virtual Private Server hosting services.

I'd like to place each service that they operate into a jail, so that if 
someone manages to bust in because of a security hole in one of the 
server programs, they would only be able to get at the contents of that 
particular jail.

But all of the jails are just subdivisions of a single operating system; 
I can't run other OSes within them.

[1] http://www.oggfrog.com/free-music-software/
     No, there is nothing to download yet.  Real Soon Now.

Mike
-- 
Michael David Crawford
mdc@prgmr.com

    prgmr.com - We Don't Assume You Are Stupid.

       Xen-Powered Virtual Private Servers: http://prgmr.com/xen
From js at alien8.de  Fri May 22 13:00:04 2009
From: js at alien8.de (Julian Stecklina)
Date: Fri May 22 13:00:09 2009
Subject: My FreeBSD-current/Xen install notes
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
	<Pine.LNX.4.64.0905192149580.6589@localhost>
	<d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>
	<20090521215221.GA98253@server.vk2pj.dyndns.org>
Message-ID: <87pre1nvl9.fsf@tabernacle.lan>

Peter Jeremy <peterjeremy@optushome.com.au> writes:

> On 2009-May-20 08:30:09 +0800, Adrian Chadd <adrian@freebsd.org> wrote:
>>Xen also lets you write "other" OSes without needing to care about the
>>hardware. One of my friends bootstrapped a toy OS of his inside Xen.
>>He can then run it on any and all Xen boxes, unmodified, regardless of
>>the underlying hardware. That really hasn't been exploited to its full
>>potential though.
>
> This isn't a particularly new idea: The 'CMS' part of IBM VM/CMS was a
> hypervisor-aware OS that couldn't run on bare metal.
>
> Relying on the hypervisor for some "traditional" OS services offers
> plenty of scope for interesting developments.  One area would be in
> University Operating Systems courses - it would again be possible to
> offer practical coursework on operating systems that are comprehendable
> in their entirety (ala V6 and Minix).

You can use microkernels[1] for almost the same thing. It's what we do
at Technische Universit?t Dresden.

Regards,
-- 
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

Footnotes: 
[1]  There is a sexy new microhypervisor to be released Real Soon
     Now(tm) too:
     http://eurosys09dw.systems.ethz.ch/steinberg.pdf

From kmacy at freebsd.org  Fri May 22 20:07:31 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Fri May 22 20:07:43 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <87pre1nvl9.fsf@tabernacle.lan>
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
	<Pine.LNX.4.64.0905192149580.6589@localhost>
	<d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>
	<20090521215221.GA98253@server.vk2pj.dyndns.org>
	<87pre1nvl9.fsf@tabernacle.lan>
Message-ID: <3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com>

> You can use microkernels[1] for almost the same thing. It's what we do
> at Technische Universit?t Dresden.
>
> Regards,
> --
> Julian Stecklina
>
> The day Microsoft makes something that doesn't suck is probably the day
> they start making vacuum cleaners - Ernst Jan Plugge
>
> Footnotes:
> [1] ?There is a sexy new microhypervisor to be released Real Soon
> ? ? Now(tm) too:
> ? ? http://eurosys09dw.systems.ethz.ch/steinberg.pdf
>

Based on L4Linux, I believe that the amount of work required for
porting a PV OS is much less than creating a new "personality" for a
microkernel. That said, isn't a hypervisor really a microkernel with
device and virtual memory abstraction API?

Cheers,
Kip
From js at alien8.de  Sat May 23 01:24:02 2009
From: js at alien8.de (Julian Stecklina)
Date: Sat May 23 01:24:09 2009
Subject: My FreeBSD-current/Xen install notes
In-Reply-To: <3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com>
	(Kip Macy's message of "Fri\, 22 May 2009 12\:46\:20 -0700")
References: <d763ac660905180553x5c7b3c5bq61acab3d28810a24@mail.gmail.com>
	<Pine.LNX.4.64.0905190807290.887@localhost>
	<d763ac660905182052t294e588bu593f1d660aef8b52@mail.gmail.com>
	<Pine.LNX.4.64.0905190944510.1090@localhost>
	<d763ac660905190631p2ff604b0gaa12ee3026b91ebc@mail.gmail.com>
	<Pine.LNX.4.64.0905192149580.6589@localhost>
	<d763ac660905191730n2d6313edhac6c866de20f137d@mail.gmail.com>
	<20090521215221.GA98253@server.vk2pj.dyndns.org>
	<87pre1nvl9.fsf@tabernacle.lan>
	<3c1674c90905221246x6323cd25w99664334c6a6a2c4@mail.gmail.com>
Message-ID: <87octk4no3.fsf@tabernacle.lan>

Kip Macy <kmacy@freebsd.org> writes:

> Based on L4Linux, I believe that the amount of work required for
> porting a PV OS is much less than creating a new "personality" for a
> microkernel. That said, isn't a hypervisor really a microkernel with
> device and virtual memory abstraction API?

OS personalities were a promise that was always brought up with
microkernels, but never really delivered. Although, L4Linux could be
seen as "Linux personality" for L4. The nice thing about microkernels is
that they abstract enough of the underlying hardware to be open for a
lot of experimenting. I think this is quite nice for student projects.

On the microkernel vs. hypervisor topic: L4 has a very nice virtual
memory abstraction and you can build device abstraction quite easily on
top of it. If you only want paravirtualization, L4 could have delivered
that years before Xen did. And actually it did: L4Linux exists for quite
some time and I believe that there was also a paper on live migration of
L4Linux instances way before Xen did that. IMHO given some commercial
support (and some foresight), L4 could have been the better Xen.

Regards,
-- 
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge
From adrian at freebsd.org  Sat May 23 10:46:28 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sat May 23 10:46:34 2009
Subject: FreeBSD-current Xen image
Message-ID: <d763ac660905230346q77d3f511oc7ba21cc0559b302@mail.gmail.com>

I've put up a recent FreeBSD-current Xen DomU image at
http://people.freebsd.org/~adrian/xen/ .

* the image is a gzip'ed 512meg filesystem installworld/distribution
install, around 208 mb.
* it includes the grub bootloader info (/boot/grub/menu.lst); a basic
/etc/fstab w/ root on "xvd0" and swap on "xvd1", and the xen console
(xc0) in /etc/ttys.
* The config file in that directory (freebsd-current.sxp) works for
me. It assumes one network interface and two block devices on LVM -
one for root, one for swap.

You should be able to just dd the image into an LVM slice or modify
the configuration to use a file (tap:aio IIRC), then "xm create
/path/to/file" . "xm console" will give you a working console.

Bonus points to you if you then figure out the magic required to boot
it to single user mode to run "growfs", then "tunefs -n enable" to
enable softupdates, with the requisite fscks and reboots to make sure
things stay consistent. I'll document that later.

I'm working on DomU releng_7 and releng_6 images at the moment but I'm
stuck with a buildworld issue and a kernel panic, respectively.

Have fun;


Adrian
From adrian at freebsd.org  Sun May 24 03:26:31 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 03:26:43 2009
Subject: Default Xen PVM console?
Message-ID: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>

G'day,

I'd like to twiddle the Xen console stuff a little bit to make it
easier to bootstrap a PVM.

There's a couple of options I can think of:

* Patch /etc/ttys to have a default "xc0" Xen console, but disabled
(which makes it trivial for users / scripts to disable the syscons
console and enable the xc console);
* Modify the xenconsole driver to attach to ttyv0 (via a kernel
environment variable) so /etc/ttys doesn't need modifying (but this
may confuse tools that assumes /dev/ttyvX == syscons.)

Opinions? I'd like to sneak in one of these before the release process
begins for 8.0.

Thanks,


Adrian
From scottl at samsco.org  Sun May 24 04:50:46 2009
From: scottl at samsco.org (Scott Long)
Date: Sun May 24 04:50:54 2009
Subject: Default Xen PVM console?
In-Reply-To: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
Message-ID: <4A18CA0D.6050805@samsco.org>

Adrian Chadd wrote:
> G'day,
> 
> I'd like to twiddle the Xen console stuff a little bit to make it
> easier to bootstrap a PVM.
> 
> There's a couple of options I can think of:
> 
> * Patch /etc/ttys to have a default "xc0" Xen console, but disabled
> (which makes it trivial for users / scripts to disable the syscons
> console and enable the xc console);
> * Modify the xenconsole driver to attach to ttyv0 (via a kernel
> environment variable) so /etc/ttys doesn't need modifying (but this
> may confuse tools that assumes /dev/ttyvX == syscons.)
> 
> Opinions? I'd like to sneak in one of these before the release process
> begins for 8.0.
> 
> Thanks,

Treat xen as a new platform and have a src/etc/etc.xen directory that 
holds the xen-specific ttys files, along with similar things that it'll
likely need.

Scott
From ed at 80386.nl  Sun May 24 09:14:38 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sun May 24 09:14:50 2009
Subject: Default Xen PVM console?
In-Reply-To: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
Message-ID: <20090524091436.GR1271@hoeg.nl>

* Adrian Chadd <adrian@freebsd.org> wrote:
> * Modify the xenconsole driver to attach to ttyv0 (via a kernel
> environment variable) so /etc/ttys doesn't need modifying (but this
> may confuse tools that assumes /dev/ttyvX == syscons.)

Please don't. Someone on IRC told me Xen also has some framebuffer
feature. Say, someone would port syscons to Xen, the naming would
conflict with the console device node. /dev/xc0 is good enough. I even
think it should have been called ttyx0, not xc0.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-xen/attachments/20090524/527b10c1/attachment.pgp
From adrian at freebsd.org  Sun May 24 09:37:26 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 09:37:38 2009
Subject: Default Xen PVM console?
In-Reply-To: <20090524091436.GR1271@hoeg.nl>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<20090524091436.GR1271@hoeg.nl>
Message-ID: <d763ac660905240237x2b82e074of0b7c71310f81a97@mail.gmail.com>

2009/5/24 Ed Schouten <ed@80386.nl>:
> * Adrian Chadd <adrian@freebsd.org> wrote:
>> * Modify the xenconsole driver to attach to ttyv0 (via a kernel
>> environment variable) so /etc/ttys doesn't need modifying (but this
>> may confuse tools that assumes /dev/ttyvX == syscons.)
>
> Please don't. Someone on IRC told me Xen also has some framebuffer
> feature. Say, someone would port syscons to Xen, the naming would
> conflict with the console device node. /dev/xc0 is good enough. I even
> think it should have been called ttyx0, not xc0.

It sounds like I should just stick to modifying etc/ttys then. I'll
see about getting consensus on the right way of doing that and then do
it in the next couple days.


Thanks,


Adrian
From adrian at freebsd.org  Sun May 24 09:39:19 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 09:39:31 2009
Subject: Default Xen PVM console?
In-Reply-To: <4A18CA0D.6050805@samsco.org>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<4A18CA0D.6050805@samsco.org>
Message-ID: <d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>

2009/5/24 Scott Long <scottl@samsco.org>:

> Treat xen as a new platform and have a src/etc/etc.xen directory that holds
> the xen-specific ttys files, along with similar things that it'll
> likely need.

In -theory- there could be Xen PVM support for i386, amd64 and ia64;
with apparently some random work being done on ARM support in the
future.

I'll chat on IRC with you/others about the most likely sensible way of
doing this and then post a summary to the list(s).

Thanks,


Adrian
From adrian at freebsd.org  Sun May 24 09:44:54 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 09:45:00 2009
Subject: Default Xen PVM console?
In-Reply-To: <d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<4A18CA0D.6050805@samsco.org>
	<d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>
Message-ID: <d763ac660905240244v7f58c813q49d8841bff270eb3@mail.gmail.com>

Ed has also suggested renaming the console device to "ttyx0" to keep
in line with the "typical TTY name in BSDs."



Adrian
From rwatson at FreeBSD.org  Sun May 24 09:45:49 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun May 24 09:45:56 2009
Subject: Default Xen PVM console?
In-Reply-To: <20090524091436.GR1271@hoeg.nl>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<20090524091436.GR1271@hoeg.nl>
Message-ID: <alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>

On Sun, 24 May 2009, Ed Schouten wrote:

> * Adrian Chadd <adrian@freebsd.org> wrote:
>> * Modify the xenconsole driver to attach to ttyv0 (via a kernel environment 
>> variable) so /etc/ttys doesn't need modifying (but this may confuse tools 
>> that assumes /dev/ttyvX == syscons.)
>
> Please don't. Someone on IRC told me Xen also has some framebuffer feature. 
> Say, someone would port syscons to Xen, the naming would conflict with the 
> console device node. /dev/xc0 is good enough. I even think it should have 
> been called ttyx0, not xc0.

Given that there will be increasing levels of support for "pass-through" 
hardware access in virtual machine environments and a trend in the direction 
of virtualization-friendly hardware, we shouldn't preclude the possibility of 
something a lot closer to syscons working inside of Xen in the future.  This 
means we should leave the syscons device names open so that syscons can claim 
them if desired.

Robert N M Watson
Computer Laboratory
University of Cambridge
From ed at 80386.nl  Sun May 24 11:19:13 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sun May 24 11:19:24 2009
Subject: Default Xen PVM console?
In-Reply-To: <alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<20090524091436.GR1271@hoeg.nl>
	<alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>
Message-ID: <20090524111910.GS1271@hoeg.nl>

* Robert Watson <rwatson@FreeBSD.org> wrote:
> Given that there will be increasing levels of support for "pass-through"  
> hardware access in virtual machine environments and a trend in the 
> direction of virtualization-friendly hardware, we shouldn't preclude the 
> possibility of something a lot closer to syscons working inside of Xen in 
> the future.  This means we should leave the syscons device names open so 
> that syscons can claim them if desired.

Yes, exactly!

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-xen/attachments/20090524/a29df1e2/attachment.pgp
From scottl at samsco.org  Sun May 24 11:25:03 2009
From: scottl at samsco.org (Scott Long)
Date: Sun May 24 11:25:16 2009
Subject: Default Xen PVM console?
In-Reply-To: <d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>	
	<4A18CA0D.6050805@samsco.org>
	<d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>
Message-ID: <4A192E8B.2030204@samsco.org>

Adrian Chadd wrote:
> 2009/5/24 Scott Long <scottl@samsco.org>:
> 
>> Treat xen as a new platform and have a src/etc/etc.xen directory that holds
>> the xen-specific ttys files, along with similar things that it'll
>> likely need.
> 
> In -theory- there could be Xen PVM support for i386, amd64 and ia64;
> with apparently some random work being done on ARM support in the
> future.

Once you start shifting away from full HVM mode, the instruction set 
architecture starts becoming much less relevant.  Anything using the
xc driver is going to behave pretty much the same in respect to the
ttys file, regardless of if it's i386 or amd64 or arm.

Scott
From scottl at samsco.org  Sun May 24 11:27:05 2009
From: scottl at samsco.org (Scott Long)
Date: Sun May 24 11:27:15 2009
Subject: Default Xen PVM console?
In-Reply-To: <d763ac660905240244v7f58c813q49d8841bff270eb3@mail.gmail.com>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>	
	<4A18CA0D.6050805@samsco.org>	
	<d763ac660905240239p46480eefl891783533d99e886@mail.gmail.com>
	<d763ac660905240244v7f58c813q49d8841bff270eb3@mail.gmail.com>
Message-ID: <4A192F05.7040104@samsco.org>

Adrian Chadd wrote:
> Ed has also suggested renaming the console device to "ttyx0" to keep
> in line with the "typical TTY name in BSDs."
> 

I don't think that the loss of continuity in naming here is a very
good idea.  It's been over 15 years, that qualifies as "typical TTY
name for FreeBSD".

Scott
From scottl at samsco.org  Sun May 24 11:31:56 2009
From: scottl at samsco.org (Scott Long)
Date: Sun May 24 11:32:08 2009
Subject: Default Xen PVM console?
In-Reply-To: <alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>	<20090524091436.GR1271@hoeg.nl>
	<alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>
Message-ID: <4A19300A.1020906@samsco.org>

Robert Watson wrote:
> On Sun, 24 May 2009, Ed Schouten wrote:
> 
>> * Adrian Chadd <adrian@freebsd.org> wrote:
>>> * Modify the xenconsole driver to attach to ttyv0 (via a kernel 
>>> environment variable) so /etc/ttys doesn't need modifying (but this 
>>> may confuse tools that assumes /dev/ttyvX == syscons.)
>>
>> Please don't. Someone on IRC told me Xen also has some framebuffer 
>> feature. Say, someone would port syscons to Xen, the naming would 
>> conflict with the console device node. /dev/xc0 is good enough. I even 
>> think it should have been called ttyx0, not xc0.
> 
> Given that there will be increasing levels of support for "pass-through" 
> hardware access in virtual machine environments and a trend in the 
> direction of virtualization-friendly hardware, we shouldn't preclude the 
> possibility of something a lot closer to syscons working inside of Xen 
> in the future.  This means we should leave the syscons device names open 
> so that syscons can claim them if desired.
> 

HVM mode already supports "pass-through" with syscons working in it.
That is orthogonal to the discussion of supporting the native
virtualization features of Xen.

Scott
From rwatson at FreeBSD.org  Sun May 24 11:46:27 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun May 24 11:46:50 2009
Subject: Default Xen PVM console?
In-Reply-To: <4A19300A.1020906@samsco.org>
References: <d763ac660905232026n6542fd17k8f6c8625543be4fa@mail.gmail.com>
	<20090524091436.GR1271@hoeg.nl>
	<alpine.BSF.2.00.0905241043360.75344@fledge.watson.org>
	<4A19300A.1020906@samsco.org>
Message-ID: <alpine.BSF.2.00.0905241245120.75344@fledge.watson.org>

On Sun, 24 May 2009, Scott Long wrote:

>>> Please don't. Someone on IRC told me Xen also has some framebuffer 
>>> feature. Say, someone would port syscons to Xen, the naming would conflict 
>>> with the console device node. /dev/xc0 is good enough. I even think it 
>>> should have been called ttyx0, not xc0.
>> 
>> Given that there will be increasing levels of support for "pass-through" 
>> hardware access in virtual machine environments and a trend in the 
>> direction of virtualization-friendly hardware, we shouldn't preclude the 
>> possibility of something a lot closer to syscons working inside of Xen in 
>> the future.  This means we should leave the syscons device names open so 
>> that syscons can claim them if desired.
>
> HVM mode already supports "pass-through" with syscons working in it. That is 
> orthogonal to the discussion of supporting the native virtualization 
> features of Xen.

Not sure I follow this comment: what I'm saying is that the Xen-specific 
console device should not use the same device names as syscons, so that the 
two can coexist in a single installation.

Robert N M Watson
Computer Laboratory
University of Cambridge
From adrian at freebsd.org  Sun May 24 14:14:37 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 14:14:43 2009
Subject: freebsd-xen images
Message-ID: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>

I've just written up a wiki page which links to the images that I'm toying with.

http://wiki.freebsd.org/AdrianChadd/XenImages

My build script is there; there's also notes on what I've done to make
a base build/install work as a DomU and how to call makefs to build an
initial image. It should be enough for people to bootstrap a
FreeBSD/Xen DomU to evaluate.

I'm currently trying out the freebsd-6.3-release image that I've built
and it is currently uploading for others to test out. It seems
slightly more stable than the freebsd releng_6 image. FreeBSD-current
is stable except for a repeatable VM page bug which I'm looking at
(but Kip will almost certainly beat me to it) and I as of yet haven't
successfully built a releng_7 xen image.

I hope this has taken all of the mystery out of bootstrapping a
FreeBSD/Xen DomU. :)

Thanks,


Adrian
From fb-xen at psconsult.nl  Sun May 24 15:50:18 2009
From: fb-xen at psconsult.nl (Paul Schenkeveld)
Date: Sun May 24 15:50:26 2009
Subject: freebsd-xen images
In-Reply-To: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
Message-ID: <20090524151025.GA67024@psconsult.nl>

On Sun, May 24, 2009 at 10:14:36PM +0800, Adrian Chadd wrote:
> I've just written up a wiki page which links to the images that I'm toying with.
> 
> http://wiki.freebsd.org/AdrianChadd/XenImages

Thanks a lot!  Nice to see all that recent activity on FreeBSD dom0!

Over the last 12 months or so I've tried several times to get a working
dom0 to try the FreeBSD Xen bits on but being a complete Lunix nono,
three attempts with Linux failed (with Centos 5.0 - xen too old,
OpenSuse 11.0 - system wouldn't boot after vanilla install, and Centos
5.2 - I stalled trying to get all the software installed to run Xen).

At EuroBSDcon 2008 I had a talk with Michael Dexter about using a netbsd
Dom0 (see http://multiplicity.bsd.lv/) but only 'almost' got it to work
but choked on getting a grub working on 64-bit netbsd and other
challenges.

Yesterday I decided to try again from the beginning, now with Solaris
Express Community Edition build 114 after a chat with a good friend
working at Sun.  I finally got a working setup, under VMware Fusion
first but now starting installation on a freed up quad core workstation.

This all shows that getting a dom0 up and running can be a challenge if
you're not Linux literate.  Are there any more detailed resources on the
net about "getting your first dom0 that's capable of running FreeBSD domU
up and running for newbies"?

The weekend is almost over so $WORK will take over my agenda soon.
If no good resources are available I'm willing to spend more time on
this and write up notes to be put on the wiki.

Regards,

Paul Schenkeveld
From adrian at freebsd.org  Sun May 24 15:56:06 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 24 15:56:13 2009
Subject: freebsd-xen images
In-Reply-To: <20090524151025.GA67024@psconsult.nl>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
	<20090524151025.GA67024@psconsult.nl>
Message-ID: <d763ac660905240855m5118e3b8j6ef9ad81c0f021db@mail.gmail.com>

2009/5/24 Paul Schenkeveld <fb-xen@psconsult.nl>:

> Thanks a lot! ?Nice to see all that recent activity on FreeBSD dom0!

FreeBSD DomU you mean? :) There's no FreeBSD dom0 support.

> This all shows that getting a dom0 up and running can be a challenge if
> you're not Linux literate. ?Are there any more detailed resources on the
> net about "getting your first dom0 that's capable of running FreeBSD domU
> up and running for newbies"?

Yup!


The way is simple:

* grab centos 5.3, i386 edition (i've not tried the 64 bit stuff)
* you uncheck all the package groups except "base", including "dial up
networking" and "text" internet
* (this means you only need CD 1, not all 6.)
* Install the base system
* reboot, make sure everything is fine, run "yum update", fiddle with
things as needed

* Then "yum install xen"
* make sure /boot/grub/menu.lst is set to boot xen automatically.

That is basically it ;) There's other stuff to do (such as figuring
out how to drive their networking scripts) but the default "bridged"
eth0 is perfectly fine for basic testing.

I had trouble with my recentish intel desktop motherboard(s) - I had
to boot the installer and normal kernel with 'acpi=off' but -not- boot
Xen with that.




Adrian
From paul at psconsult.nl  Sun May 24 18:50:20 2009
From: paul at psconsult.nl (Paul Schenkeveld)
Date: Sun May 24 18:50:26 2009
Subject: freebsd-xen images
In-Reply-To: <d763ac660905240855m5118e3b8j6ef9ad81c0f021db@mail.gmail.com>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
	<20090524151025.GA67024@psconsult.nl>
	<d763ac660905240855m5118e3b8j6ef9ad81c0f021db@mail.gmail.com>
Message-ID: <20090524181826.GA76477@psconsult.nl>

On Sun, May 24, 2009 at 11:55:57PM +0800, Adrian Chadd wrote:
> 2009/5/24 Paul Schenkeveld <fb-xen@psconsult.nl>:
> 
> > Thanks a lot! ?Nice to see all that recent activity on FreeBSD dom0!
> 
> FreeBSD DomU you mean? :) There's no FreeBSD dom0 support.

Yes of course.  (or was it widhful thinking?)

> > This all shows that getting a dom0 up and running can be a challenge if
> > you're not Linux literate. ?Are there any more detailed resources on the
> > net about "getting your first dom0 that's capable of running FreeBSD domU
> > up and running for newbies"?
> 
> Yup!
> 
> 
> The way is simple:

<would_be_nice_if_this_were_on_the_freebsd_wiki>
> * grab centos 5.3, i386 edition (i've not tried the 64 bit stuff)
> * you uncheck all the package groups except "base", including "dial up
> networking" and "text" internet
> * (this means you only need CD 1, not all 6.)
> * Install the base system
> * reboot, make sure everything is fine, run "yum update", fiddle with
> things as needed
> 
> * Then "yum install xen"
> * make sure /boot/grub/menu.lst is set to boot xen automatically.
> 
> That is basically it ;) There's other stuff to do (such as figuring
> out how to drive their networking scripts) but the default "bridged"
> eth0 is perfectly fine for basic testing.
</would_be_nice_if_this_were_on_the_freebsd_wiki>

> I had trouble with my recentish intel desktop motherboard(s) - I had
> to boot the installer and normal kernel with 'acpi=off' but -not- boot
> Xen with that.

Which board model(s)?  I've just installed Solaris on a DP35DP with Q6600
core-2 duo and 8GB RAM.  Works nice (except for USB-legacy making the
keyboard useless during boot).

> Adrian

Thanks again for the great work on Xen!

-- Paul Schenkeveld
From adrian at freebsd.org  Mon May 25 01:38:41 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 25 01:38:47 2009
Subject: freebsd-xen images
In-Reply-To: <20090524181826.GA76477@psconsult.nl>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
	<20090524151025.GA67024@psconsult.nl>
	<d763ac660905240855m5118e3b8j6ef9ad81c0f021db@mail.gmail.com>
	<20090524181826.GA76477@psconsult.nl>
Message-ID: <d763ac660905241838u8021c61p2a964e57b1b24c00@mail.gmail.com>

2009/5/25 Paul Schenkeveld <paul@psconsult.nl>:

> <would_be_nice_if_this_were_on_the_freebsd_wiki>

I was going to document my Xen server setup later on, including some
information from my testing.

To summarise - RHEL/Centos seem quite happy(!) on the xen 2.6.18
kernel whilst backporting drivers; others have forward ported Xen.
I've had all kinds of weird crap happen with Debian/Ubuntu. Fedora
Core has been trying to forward port stuff too and integrate it all
into the paravirt ops framework so I think their dom0 support has been
busted until very recently.

I'll dump this into the Wiki when I get time.


>> I had trouble with my recentish intel desktop motherboard(s) - I had
>> to boot the installer and normal kernel with 'acpi=off' but -not- boot
>> Xen with that.
>
> Which board model(s)? ?I've just installed Solaris on a DP35DP with Q6600
> core-2 duo and 8GB RAM. ?Works nice (except for USB-legacy making the
> keyboard useless during boot).

I don't recall off-hand; I'll look at my documentation later and put
it in the Wiki.



adrian
From adrian at FreeBSD.org  Mon May 25 05:48:17 2009
From: adrian at FreeBSD.org (adrian@FreeBSD.org)
Date: Mon May 25 05:48:23 2009
Subject: i386/134926: FreeBSD-current Xen DomU networking panic - out of
	tx mbufs?
Message-ID: <200905250548.n4P5mGpD017462@freefall.freebsd.org>

Synopsis: FreeBSD-current Xen DomU networking panic - out of tx mbufs?

Responsible-Changed-From-To: freebsd-i386->freebsd-xen
Responsible-Changed-By: adrian
Responsible-Changed-When: Mon May 25 05:47:55 UTC 2009
Responsible-Changed-Why: 
Over to maintainer


http://www.freebsd.org/cgi/query-pr.cgi?pr=134926
From fb-xen at psconsult.nl  Mon May 25 06:35:25 2009
From: fb-xen at psconsult.nl (Paul Schenkeveld)
Date: Mon May 25 06:35:32 2009
Subject: freebsd-xen images
In-Reply-To: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
Message-ID: <20090525063518.GA82256@psconsult.nl>

On Sun, May 24, 2009 at 10:14:36PM +0800, Adrian Chadd wrote:
> I'm currently trying out the freebsd-6.3-release image that I've built
> and it is currently uploading for others to test out. It seems
> slightly more stable than the freebsd releng_6 image. FreeBSD-current
> is stable except for a repeatable VM page bug which I'm looking at
> (but Kip will almost certainly beat me to it) and I as of yet haven't
> successfully built a releng_7 xen image.

One small issue with the 6.3 image, after executing halt or halt -p in
the domU, it always immediately reboots.  To really stop it one has to
'xm destroy' from dom0.

(dom0 is Solaris Express Community Edition if that matters, I'm still
trying to find out what version of Xen is included).

-- Paul Schenkeveld
From adrian at freebsd.org  Mon May 25 06:43:56 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon May 25 06:44:02 2009
Subject: freebsd-xen images
In-Reply-To: <20090525063518.GA82256@psconsult.nl>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
	<20090525063518.GA82256@psconsult.nl>
Message-ID: <d763ac660905242343m30273c19t7b4b0f900094dbe7@mail.gmail.com>

2009/5/25 Paul Schenkeveld <fb-xen@psconsult.nl>:

> One small issue with the 6.3 image, after executing halt or halt -p in
> the domU, it always immediately reboots.  To really stop it one has to
> 'xm destroy' from dom0.

I've noticed some "weird stuff" like that. Would you please run
'send-pr' in the VM and submit a PR with a description/etc? That way
it is documented.

> (dom0 is Solaris Express Community Edition if that matters, I'm still
> trying to find out what version of Xen is included).

"xm dmesg" and "xm info" are helpful commands here.




Adrian
From bugmaster at FreeBSD.org  Mon May 25 11:07:06 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon May 25 11:10:40 2009
Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org
Message-ID: <200905251107.n4PB7441093025@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o i386/134926  xen        FreeBSD-current Xen DomU networking panic - out of tx 

1 problem total.

From dfilter at FreeBSD.ORG  Wed May 27 02:50:03 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Wed May 27 02:50:14 2009
Subject: i386/134926: commit references a PR
Message-ID: <200905270250.n4R2o2Yn094175@freefall.freebsd.org>

The following reply was made to PR i386/134926; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/134926: commit references a PR
Date: Wed, 27 May 2009 02:49:22 +0000 (UTC)

 Author: adrian
 Date: Wed May 27 02:49:08 2009
 New Revision: 192871
 URL: http://svn.freebsd.org/changeset/base/192871
 
 Log:
   Ensure that there are enough TX mbuf ring slots available before beginning
   to dequeue a packet.
   
   The tx path was trying to ensure that enough Xenbus TX ring slots existed but
   it didn't check to see whether the mbuf TX ring slots were also available.
   They get freed in xn_txeof() which occurs after transmission, rather than earlier
   on in the process. (The same happens under Linux too.)
   
   Due to whatever reason (CPU use, scheduling, memory constraints, whatever) the
   mbuf TX ring may not have enough slots free and would allocate slot 0. This is
   used as the freelist head pointer to represent "free" mbuf TX ring slots; setting
   this to an actual mbuf value rather than an id crashes the code.
   
   This commit introduces some basic code to track the TX mbuf ring use and then
   (hopefully!) ensures that enough slots are free in said TX mbuf ring before it
   enters the actual work loop.
   
   A few notes:
   
   * Similar logic needs to be introduced to check there are enough actual slots
     available in the xenbuf TX ring. There's some logic which is invoked earlier
     but it doesn't hard-check against the number of available ring slots.
     Its trivial to do; I'll do it in a subsequent commit.
   
   * As I've now commented in the source, it is likely possible to deadlock the
     driver under certain conditions where the rings aren't receiving any changes
     (which I should enumerate) and thus Xen doesn't send any further software
     interrupts. I need to make sure that the timer(s) are running right and
     the queues are periodically kicked.
   
   PR:		134926
 
 Modified:
   head/sys/dev/xen/netfront/netfront.c
 
 Modified: head/sys/dev/xen/netfront/netfront.c
 ==============================================================================
 --- head/sys/dev/xen/netfront/netfront.c	Wed May 27 01:56:37 2009	(r192870)
 +++ head/sys/dev/xen/netfront/netfront.c	Wed May 27 02:49:08 2009	(r192871)
 @@ -176,6 +176,7 @@ static int xennet_get_responses(struct n
   */
  struct xn_chain_data {
  		struct mbuf		*xn_tx_chain[NET_TX_RING_SIZE+1];
 +		int			xn_tx_chain_cnt;
  		struct mbuf		*xn_rx_chain[NET_RX_RING_SIZE+1];
  };
  
 @@ -727,6 +728,10 @@ netif_release_tx_bufs(struct netfront_in
  		    np->grant_tx_ref[i]);
  		np->grant_tx_ref[i] = GRANT_INVALID_REF;
  		add_id_to_freelist(np->tx_mbufs, i);
 +		np->xn_cdata.xn_tx_chain_cnt--;
 +		if (np->xn_cdata.xn_tx_chain_cnt < 0) {
 +			panic("netif_release_tx_bufs: tx_chain_cnt must be >= 0");
 +		}
  		m_freem(m);
  	}
  }
 @@ -1089,6 +1094,10 @@ xn_txeof(struct netfront_info *np)
  			
  			np->xn_cdata.xn_tx_chain[id] = NULL;
  			add_id_to_freelist(np->xn_cdata.xn_tx_chain, id);
 +			np->xn_cdata.xn_tx_chain_cnt--;
 +			if (np->xn_cdata.xn_tx_chain_cnt < 0) {
 +				panic("netif_release_tx_bufs: tx_chain_cnt must be >= 0");
 +			}
  			m_free(m);
  		}
  		np->tx.rsp_cons = prod;
 @@ -1417,7 +1426,6 @@ xn_start_locked(struct ifnet *ifp) 
  			ifp->if_drv_flags |= IFF_DRV_OACTIVE;
  			break;
  		}
 -		
  
  		/*
  		 * Defragment the mbuf if necessary.
 @@ -1433,6 +1441,36 @@ xn_start_locked(struct ifnet *ifp) 
  			m_head = m;
  		}
  
 +		/* Determine how many fragments now exist */
 +		for (m = m_head, nfrags = 0; m; m = m->m_next)
 +			nfrags++;
 +
 +		/*
 +		 * Don't attempt to queue this packet if there aren't enough free entries in the chain.
 +		 * There isn't a 1:1 correspondance between the mbuf TX ring and the xenbus TX ring.
 +		 * xn_txeof() may need to be called to free up some slots.
 +		 *
 +		 * It is quite possible that this can be later eliminated if it turns out that partial
 +		 * packets can be pushed into the ringbuffer, with fragments pushed in when further slots
 +		 * free up.
 +		 *
 +		 * It is also quite possible that the driver will lock up - Xen may not send another
 +		 * interrupt to kick the tx/rx processing if the xenbus RX ring is full and xenbus TX ring
 +		 * is empty - no further TX work can be done until space is made in the TX mbuf ring and
 +		 * the RX side may be waiting for TX data to continue. It is quite possible some timer
 +		 * event should be created to kick TX/RX processing along in certain conditions.
 +		 */
 +
 +		/* its not +1 like the allocation because we need to keep slot [0] free for the freelist head */
 +		if (sc->xn_cdata.xn_tx_chain_cnt + nfrags >= NET_TX_RING_SIZE) {
 +			printf("xn_start_locked: xn_tx_chain_cnt (%d) + nfrags %d >= NET_TX_RING_SIZE (%d); must be full!\n",
 +			    (int) sc->xn_cdata.xn_tx_chain_cnt, (int) nfrags, (int) NET_TX_RING_SIZE);
 +			IF_PREPEND(&ifp->if_snd, m_head);
 +			ifp->if_drv_flags |= IFF_DRV_OACTIVE;
 +			break;
 +		}
 +
 +
  		/*
  		 * Start packing the mbufs in this chain into
  		 * the fragment pointers. Stop when we run out
 @@ -1443,6 +1481,11 @@ xn_start_locked(struct ifnet *ifp) 
  		for (m = m_head; m; m = m->m_next) {
  			tx = RING_GET_REQUEST(&sc->tx, i);
  			id = get_id_from_freelist(sc->xn_cdata.xn_tx_chain);
 +			if (id == 0)
 +				panic("xn_start_locked: was allocated the freelist head!\n");
 +			sc->xn_cdata.xn_tx_chain_cnt++;
 +			if (sc->xn_cdata.xn_tx_chain_cnt >= NET_TX_RING_SIZE+1)
 +				panic("xn_start_locked: tx_chain_cnt must be < NET_TX_RING_SIZE+1\n");
  			sc->xn_cdata.xn_tx_chain[id] = m;
  			tx->id = id;
  			ref = gnttab_claim_grant_reference(&sc->gref_tx_head);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From adrian at freebsd.org  Wed May 27 06:30:09 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed May 27 06:30:16 2009
Subject: netfront changes (was Re: i386/134926: FreeBSD-current Xen DomU 
	networking panic - out of tx mbufs?)
Message-ID: <d763ac660905262330j1db0bd87t4162af0043b4243d@mail.gmail.com>

G'day,

I've committed some sanity checking code to the FreeBSD-current/Xen
netfront drivers. The driver now ensures there are TX mbuf and xen TX
ring descriptor slots available before it queues a packet.

There's some debugging printf()'s that will spit out messages when
things go awry, eg:

xn_start_locked: xn_tx_chain_cnt (254) + nfrags 2 >= NET_TX_RING_SIZE
(256); must be full!
xn_start_locked: xn_tx_chain_cnt (255) + nfrags 1 >= NET_TX_RING_SIZE
(256); must be full!

This seems to have ceased the panics under CPU/memory pressure on my
playpen server.

I'm going to continue tidying up the netfront driver a little more
over the next few days to hopefully wrap up some dangling loose ends
which I can see. I'd appreciate it if people could give
FreeBSD-current/Xen a right royal thrashing (eg, 4 FreeBSD vms on one
host pegging network and CPU traffic at maximum between each other) to
try and elicit any other crazy network behaviour. There's only so much
I can test atm.

Thanks,


Adrian




Adrian
From adrian at FreeBSD.org  Thu May 28 04:22:19 2009
From: adrian at FreeBSD.org (adrian@FreeBSD.org)
Date: Thu May 28 04:22:25 2009
Subject: kern/135008: FreeBSD-current/Xen timecounter jumps
Message-ID: <200905280422.n4S4MIks023811@freefall.freebsd.org>

Synopsis: FreeBSD-current/Xen timecounter jumps

Responsible-Changed-From-To: freebsd-bugs->freebsd-xen
Responsible-Changed-By: adrian
Responsible-Changed-When: Thu May 28 04:21:40 UTC 2009
Responsible-Changed-Why: 
Over to maintainer.


http://www.freebsd.org/cgi/query-pr.cgi?pr=135008
From adrian at freebsd.org  Thu May 28 04:50:03 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Thu May 28 04:50:09 2009
Subject: kern/135008: FreeBSD-current/Xen timecounter jumps
Message-ID: <200905280450.n4S4o3EJ041623@freefall.freebsd.org>

The following reply was made to PR kern/135008; it has been noted by GNATS.

From: Adrian Chadd <adrian@freebsd.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/135008: FreeBSD-current/Xen timecounter jumps
Date: Thu, 28 May 2009 12:25:45 +0800

 .. now that the RTC code is in and I've figured out whats going on
 there, the problem has become obvious.
 
 Changing the dom0 clock by > 1 second seems to trigger a re-read of
 the wall clock in the DomU. The DomU sets the TOD to the wall clock -
 but this unfortunately sets it to the hypervisor start time rather
 than including the start time + uptime.
 
 The fix is to figure out the code path(s) in the xen clock code and
 fix the TOD update to be correct.
From adrian at freebsd.org  Thu May 28 06:39:41 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Thu May 28 06:39:49 2009
Subject: Update: Xen, networking, RTC and clocks
Message-ID: <d763ac660905272339w7ae380feh474bb2b804648015@mail.gmail.com>

G'day,

I've committed a basic Xen Hypervisor RTC to FreeBSD-current. The time
is now correctly synced to the hypervisor TOD clock.

I've figured out the "weirdness" in the running clock and time of day
changes. Updates to the Dom0 clock will touch the hypervisor clock.
The current -current logic doesn't read the Xen hypervisor TOD and so
a drift of > 1 second seems to set the -current TOD clock to the wrong
value (actually, the "hypervisor start" TOD. :)

I've also fixed some memory exhaustion issues in the netfront driver.
It now doesn't panic for me under stress.

Anyway. I'd appreciate it if people updated to the latest -current and
tested Xen out.

Thanks,



Adrian
From js at alien8.de  Thu May 28 12:14:36 2009
From: js at alien8.de (Julian Stecklina)
Date: Thu May 28 12:14:43 2009
Subject: Update: Xen, networking, RTC and clocks
References: <d763ac660905272339w7ae380feh474bb2b804648015@mail.gmail.com>
Message-ID: <873aaps9ur.fsf@tabernacle.lan>

Adrian Chadd <adrian@freebsd.org> writes:

> G'day,
>
> I've committed a basic Xen Hypervisor RTC to FreeBSD-current. The time
> is now correctly synced to the hypervisor TOD clock.

Thank you! If I ever see you in person, remind me to buy you a beer or
two. :)

> Anyway. I'd appreciate it if people updated to the latest -current and
> tested Xen out.

I'll try to do that in the next couple of days.

Regards,
-- 
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

From adrian at freebsd.org  Fri May 29 13:45:59 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Fri May 29 13:46:05 2009
Subject: Clock TOD issues (mostly) resolved?
Message-ID: <d763ac660905290645v331d3387x2549eda596b939b8@mail.gmail.com>

G'day,

I've just committed some changes to the Xen clock code which should
resolve some of the random time jumps people may have seen when the
dom0/hypervisor clock was updated.

Please test!



Adrian
From dfilter at FreeBSD.ORG  Fri May 29 13:50:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Fri May 29 13:50:16 2009
Subject: kern/135008: commit references a PR
Message-ID: <200905291350.n4TDo3GF026474@freefall.freebsd.org>

The following reply was made to PR kern/135008; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/135008: commit references a PR
Date: Fri, 29 May 2009 13:43:32 +0000 (UTC)

 Author: adrian
 Date: Fri May 29 13:43:21 2009
 New Revision: 193033
 URL: http://svn.freebsd.org/changeset/base/193033
 
 Log:
   Fix the Xen TOD update when the hypervisor wall clock is nudged.
   
   The "wall clock" in the current code is actually the hypervisor start time.
   The time of day is the "start time" plus the hypervisor "uptime".
   
   Large enough bumps in the dom0 clock lead to a hypervisor "bump" which is
   implemented as a bump in the start time, not the uptime. The clock.c routines
   were reading in the hypervisor start time and then using this as the TOD.
   This meant that any hypervisor time bump would cause the FreeBSD DomU to
   set its TOD to the hypervisor start time, rather than the actual TOD.
   
   This fix is a bit hacky and some reshuffling should be done later on
   to clarify what is going on. I've left the wall clock code alone.
   (The code which updates shadow_tv and shadow_tv_version.)
   A new routine adds the uptime to the shadow_tv, which is then used to
   update the TOD.
   
   I've included some debugging so it is obvious when the clock is nudged.
   
   PR:	135008
 
 Modified:
   head/sys/i386/xen/clock.c
 
 Modified: head/sys/i386/xen/clock.c
 ==============================================================================
 --- head/sys/i386/xen/clock.c	Fri May 29 13:36:06 2009	(r193032)
 +++ head/sys/i386/xen/clock.c	Fri May 29 13:43:21 2009	(r193033)
 @@ -87,6 +87,7 @@ __FBSDID("$FreeBSD$");
  #include <machine/xen/xenfunc.h>
  #include <xen/interface/vcpu.h>
  #include <machine/cpu.h>
 +#include <machine/xen/xen_clock_util.h>
  
  /*
   * 32-bit time_t's can't reach leap years before 1904 or after 2036, so we
 @@ -236,6 +237,15 @@ static void update_wallclock(void)
  
  }
  
 +static void
 +add_uptime_to_wallclock(void)
 +{
 +	struct timespec ut;
 +
 +	xen_fetch_uptime(&ut);
 +	timespecadd(&shadow_tv, &ut);
 +}
 +
  /*
   * Reads a consistent set of time-base values from Xen, into a shadow data
   * area. Must be called with the xtime_lock held for writing.
 @@ -331,7 +341,9 @@ clkintr(void *arg)
  	 */
  	
  	if (shadow_tv_version != HYPERVISOR_shared_info->wc_version) {
 +		printf("[XEN] hypervisor wallclock nudged; nudging TOD.\n");
  		update_wallclock();
 +		add_uptime_to_wallclock();
  		tc_setclock(&shadow_tv);
  	}
  	
 @@ -542,6 +554,7 @@ domu_inittodr(time_t base)
  	struct timespec ts;
  
  	update_wallclock();
 +	add_uptime_to_wallclock();
  	
  	RTC_LOCK;
  	
 @@ -591,6 +604,7 @@ domu_resettodr(void)
  		op.u.settime.system_time = shadow->system_timestamp;
  		HYPERVISOR_dom0_op(&op);
  		update_wallclock();
 +		add_uptime_to_wallclock();
  	} else if (independent_wallclock) {
  		/* notyet */
  		;
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From Ron.Carter at cartersweb.net  Sat May 30 16:04:23 2009
From: Ron.Carter at cartersweb.net (Ron Carter)
Date: Sat May 30 16:04:30 2009
Subject: freebsd-xen images
In-Reply-To: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
References: <d763ac660905240714p10a1051bq4ecc8b9400ff83b@mail.gmail.com>
Message-ID: <A3BFD7610AD8DE4198A516C0030F535E5CBD@bronto.Carterswebnet.local>

Will this work with XenServer 5.0 or  Beta 5.5?  I saw but have not
gotten any information yet but I saw a FreeBSD based image from Citrix
that is fully virtualized.  I trying to get more information.
RC

-----Original Message-----
From: owner-freebsd-xen@freebsd.org
[mailto:owner-freebsd-xen@freebsd.org] On Behalf Of Adrian Chadd
Sent: Sunday, May 24, 2009 10:15 AM
To: freebsd-xen@freebsd.org
Subject: freebsd-xen images

I've just written up a wiki page which links to the images that I'm
toying with.

http://wiki.freebsd.org/AdrianChadd/XenImages

My build script is there; there's also notes on what I've done to make
a base build/install work as a DomU and how to call makefs to build an
initial image. It should be enough for people to bootstrap a
FreeBSD/Xen DomU to evaluate.

I'm currently trying out the freebsd-6.3-release image that I've built
and it is currently uploading for others to test out. It seems
slightly more stable than the freebsd releng_6 image. FreeBSD-current
is stable except for a repeatable VM page bug which I'm looking at
(but Kip will almost certainly beat me to it) and I as of yet haven't
successfully built a releng_7 xen image.

I hope this has taken all of the mystery out of bootstrapping a
FreeBSD/Xen DomU. :)

Thanks,


Adrian
_______________________________________________
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org"
From mister.olli at googlemail.com  Sun May 31 12:58:25 2009
From: mister.olli at googlemail.com (Mister Olli)
Date: Sun May 31 12:58:31 2009
Subject: Clock TOD issues (mostly) resolved?
In-Reply-To: <d763ac660905290645v331d3387x2549eda596b939b8@mail.gmail.com>
References: <d763ac660905290645v331d3387x2549eda596b939b8@mail.gmail.com>
Message-ID: <1243774686.12279.7.camel@phoenix.blechhirn.net>

Hi,

I just had the time to upgrade my domU to r193943 and it fixes some bugs
I've seen before in my setup:
- scp'ing the kernel file to the dom0 instance hanged after transfering 
	~ 1MB of data and did not finish. This now works perfect. I 
	hadn't got the time to test larger network transfers.
- clock jumps fully disappeared for me. I can do a complete 'make 
	buildworld' without any interruptions due to the time jump, even
	when I'm not using ntpd within the domU.

Great work Adrian. This really brings domU support forward.

Btw. do you know if there's already a PR for the reboot problem in xen
domU's? 
For me the domU does not reboot (shutdown -r ) properly and hangs after
the shutdown process is complete.
Normal shutdown (shutdown -h) works like a charm.

Regards
---
Mr. Olli

On Fri, 2009-05-29 at 21:45 +0800, Adrian Chadd wrote:
> G'day,
> 
> I've just committed some changes to the Xen clock code which should
> resolve some of the random time jumps people may have seen when the
> dom0/hypervisor clock was updated.
> 
> Please test!
> 
> 
> 
> Adrian
> _______________________________________________
> freebsd-xen@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org"

From adrian at freebsd.org  Sun May 31 13:04:21 2009
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun May 31 13:04:28 2009
Subject: Clock TOD issues (mostly) resolved?
In-Reply-To: <1243774686.12279.7.camel@phoenix.blechhirn.net>
References: <d763ac660905290645v331d3387x2549eda596b939b8@mail.gmail.com>
	<1243774686.12279.7.camel@phoenix.blechhirn.net>
Message-ID: <d763ac660905310604l6a5e1887ne8f7bd4971784b79@mail.gmail.com>

2009/5/31 Mister Olli <mister.olli@googlemail.com>:
> Hi,
>
> I just had the time to upgrade my domU to r193943 and it fixes some bugs
> I've seen before in my setup:


> - scp'ing the kernel file to the dom0 instance hanged after transfering
> ? ? ? ?~ 1MB of data and did not finish. This now works perfect. I
> ? ? ? ?hadn't got the time to test larger network transfers.

Good!

> - clock jumps fully disappeared for me. I can do a complete 'make
> ? ? ? ?buildworld' without any interruptions due to the time jump, even
> ? ? ? ?when I'm not using ntpd within the domU.

Good! The time will still drift a little until a hypervisor wall clock
sync occurs (mostly due to a large enough change to the dom0 time);
I'll investigate that later. I'm curious to know exactly how Linux
DomU's manage to keep in lock-step with the dom0 time.

> Great work Adrian. This really brings domU support forward.
>
> Btw. do you know if there's already a PR for the reboot problem in xen
> domU's?

I'm not sure. Please just create one; duplicates are better than nothing.

> For me the domU does not reboot (shutdown -r ) properly and hangs after
> the shutdown process is complete.
> Normal shutdown (shutdown -h) works like a charm.



Adrian