Re: [Xen-devel] Re: XenParavirtOps wiki page updates

[Ferenc Wagner <wferi@xxxxxxx>]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> Ferenc Wagner wrote:
>
>>  * Features in 2.6.26:
>>      Balloon (contraction only)
>>
>>    It isn't clear whether this contraction is reversible or not.
>
> It is, but only up to the original size.
>
>>  * If the domain crashes very early, before any output appears on the
>>    console, then booting with: should provide some useful information.
>>
>>    Booting with what?
>
> earlyprintk=xen

Thanks both of you for the clarification.  I pretty much expected these
answers, but wasn't entirely sure on one hand, and wanted to make sure
that this information makes it into the Wiki (where Todd accidentally
the point :)

Speaking of debugging, the dom0 serial console is highly unreliable,
it often loses characters, making the boot (and oops) messages
unreadable.  Is this just me, or is it a known deficiency?  If I boot
the kernel on bare hardware, hardware flow control keeps the serial
output intact, but the hypervisor doesn't seem to play nicely.

>>  * How to achieve time sync between the dom0 and the domUs?  Lots of
>>    people seem to have problem with domU clock drift, me included.
>>    Ntp doesn't work in domU, and apparently no clocksource guarantees
>>    such synchronization.
>
> Why doesn't ntp work?  As far as I know it should.
>
> The 2.6.18-xen kernels have a mechanism to try and sync the domains to
> the hypervisor's time, but it doesn't fit well into the current
> kernel's timekeeping.  I think either ntp or a lightweight daemon
> should be able to do this from usermode.  (I was thinking of adding
> some /sys files to publish the hypervisor's current time, which a
> daemon could use to warp the domain's time to match.)

Hmm, my last data points are from the summer, but since people keep
constantly asking on the users' list how to do this, I assumed things
didn't change.  Back then ntpd was unable to change the domU clock, it
was constantly drifting away from the current time.  Also, when the
procfs settings (like independent_wallclock) disappeared I got the
impression that the system times are now unconditionally synced.
Probably I'm just confused and all is well now...  I'll set up and
test this again.  Thanks for the hint!

>>  * The idle count doubling I still experience happens with pvops
>>    guests only (http://lkml.org/lkml/2008/9/18/276).
>
> That is pretty strange.

Yes.  Fortunately, it doesn't seem to really hurt anything, only
uglifyes our CPU graphs.

>> Otherwise, Debian's pvops guest kernel works very good for me, already
>> in production.
>
> Good to hear.  32 or 64 bit?

Right now everything is 32 bit here, but a 64 bit host is already
powered up in the basement, so sooner or later we'll test that as well.
-- 
Regards,
Feri.

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