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