[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/HVM: tie RTC emulation mode to enabling of Viridian emulation



>>> On 02.07.13 at 15:01, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Tue, Jul 2, 2013 at 11:35 AM, Tim Deegan <tim@xxxxxxx> wrote:
>> At 11:22 +0100 on 02 Jul (1372764141), Jan Beulich wrote:
>>> >>> On 02.07.13 at 11:51, Tim Deegan <tim@xxxxxxx> wrote:
>>> > At 10:27 +0100 on 02 Jul (1372760862), Jan Beulich wrote:
>>> >> >>> On 02.07.13 at 11:11, Tim Deegan <tim@xxxxxxx> wrote:
>>> >> > At 08:02 +0100 on 02 Jul (1372752161), Jan Beulich wrote:
>>> >> >> As the mode not conforming to the hardware specification (by allowing
>>> >> >> the guest to skip the REG C reads in its interrupt handler) is a
>>> >> >> Viridian invention, it seems logical to tie this mode to that 
>>> >> >> extension
>>> >> >> being enabled. If the extension is disabled, proper hardware emulation
>>> >> >> will be done instead.
>>> >> >>
>>> >> >> The main thing necessary here is the synchronization of the RTC
>>> >> >> emulation code and the setting of the respective flag in hvmloader's
>>> >> >> creation of the ACPI WAET table.
>>> >> >>
>>> >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> >> >
>>> >> > Wasn't this going to have its own param, defaulting to off on create 
>>> >> > and
>>> >> > to on on migrate?  I suspect most people just leave the viridian flag 
>>> >> > on
>>> >> > for all domains.
>>> >>
>>> >> In which case there would be no behavioral difference to what
>>> >> we're going to release with 4.3. (That's leaving aside the fact that
>>> >> I think people doing so is not the best practice.)
>>> >
>>> > Why not?  The Viridian interfaces is pretty well essential for running
>>> > recent Windows, and shouldn't be harmful for other OSes.
>>>
>>> Shouldn't. But as we learned it occasionally is - Linux when built
>>> without CONFIG_XEN_PVHVM detects the HyperV functionality,
>>> and tried using HyperV functionality that Xen doesn't really emulate
>>> (see commits 32068f65 ["x86: Hyper-V: register clocksource only if
>>> its advertised"] and db34bbb7 ["X86: Add a check to catch Xen
>>> emulation of Hyper-V"]).
>>
>> So the argument is that host admins should already be disabling this
>> for _all_ non-windows VMs to work around a bug in some linux kernels,
>> and therefore it's OK to hook this vaguely related feature onto it?
>> That seems to be below the standard that you'd expect from other
>> people.
>>
>> Anyway, surely we want this bit turned off by default even on Windows,
>> to avoid running pointless timers if Windows decides not to use the RTC.
> 
> FWIW I agree with this reasoning.  Working around bugs in Linux is a
> losing game; and disabling Viridian features that aren't a positive
> benefit to Windows seems like a good strategy.

How do you know this is not "a positive benefit"? I very much think
that to e.g. W2K3 it is - at the expense of the hypervisor having to
keep timers alive that it could otherwise put to rest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.