[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |