Re: [Xen-devel] Problems with stubdoms, and xl

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
[...]
> 1) After my winxp hvm domu, started with a stubdom, got some windows
> updates yesterday, I restarted (not shutdown), and the new domain hung
> in pause:
[..]

I tried this with win7 on xen-unstable and it worked ok. This may be a
bug specific to 4.1.

[...]
> xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"

> and only got a syntax error on the '-d'.

I don't think this approach is advised but FWIW the error here is
probably lack of quoting of the " against the shell. You would have
needed 
        ... extra=\" -d 8\"

> So my question is: is this a bug, and is it fixed in xen 4.2?

The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
it is fixed in unstable and therefore will be fixed in 4.2.

I've not been able to spot a specific changeset with the fix, but there
was quite a lot to wade through.

> 2) I'm having a strange problem right after I get a xen update from
> rawhide: stubdoms stop working for a day after wards. It happened with
> fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> whether something in /var/lib/xen* changed.

Stop working for a day and then magically starts working? Or stops
working for a day until the next update?

> 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> you
[...]
> 4) The 'localtime=1' option in your config is ignored by xl. This
> works with 
[...]
> The answer given to the two above problems at the time was essentially
> that they had not been implemented. Have they been implemented in xen
> 4.2 yet?

Not as far as I can tell with grep. Patches would be greatly
appreciated, these should be relatively simple issues for a newcomer to
tackle with only basic C required I think, I'd be glad to advise etc.

I'll add these as "nice to have" in the 4.2 TODO thread.

>  They are not mentioned in the xl.cfg documentation, which I assume is
> for 4.2:

Correct.

[...]
> Now for what does work to get a stubdom up and running. I used the
> below config, with python commented out to keep xl happy. Note the
> spice options, and 'device_model_stubdomain_override = 1' don't
> actually do anything (the latter contrary to what someone else
> reported). 

Yes, I think these are the 4.2 names, In 4.1 you likely need
        device_model = "stubdom-dm"

> I assume that they will become functional in xen 4.2.

Yes.

>  Also, while device_model_args does indeed add '-localtime' to the end
> of the qemu-dm args, it's still ineffective.

I'm not 100% sure of this but I don't think xm's "localtime" corresponds
to solely passing "-localtime" to the DM (although it may also do that
also).

I think it needs to turn into a hypercall to tell the hypervisor about
the guests time offset, e.g. a call to xc_domain_set_time_offset. The
rtc_timeoffset option relates to this call as well.

In a Xen system the RTC is emulated by the hypervisor not by qemu (it
used to be done by qemu many moons ago, which might explain the
vestigial passing of -localtime to qemu).

> And 2) If you have GPLPV installed in your domain, it completely takes
> over. Booting with GPLPV enabled is no faster with stubdoms as
> without. Booting with /nogplpv is just as slow as if you booted
> without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> doing.

If you are using PV devices then you won't be hitting the emulated
devices (which is what is in the stubdom) all that much after the very
early boot stages IOW after anything which uses BIOS int13 hook e.g. the
bootloader. If you aren't hitting the emulated devices then putting them
in stubdom vs dom0 won't make much odds to the performance.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel