[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



At 15:04 +0100 on 02 Jul (1372777451), Jan Beulich wrote:
> >>> 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.

AFAIK, Windows 8 is tickless, so presumably doesn't get any benefit from
RTC EOI tricks (but does require Viridian).

Tim.

_______________________________________________
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®.