On Thu, 31 Jan 2013, H. Peter Anvin wrote: > On 01/30/2013 12:53 AM, Jan Beulich wrote: > > > > I'm not convinced that's the right approach - any hypervisor > > could do similar emulation, and hence you either want to make > > sure you run on Hyper-V (by excluding all others), or you > > tolerate using the emulation (which may require syncing up with > > the other guest implementations so that shared resources don't > > get used by two parties). > > > > I also wonder whether using the Hyper-V emulation (where > > useful, there might not be anything right now, but this may > > change going forward) when no Xen support is configured > > wouldn't be better than not using anything... > > > > I'm confused about "the right approach" here is. As far as I > understand, this only can affect a Xen guest where HyperV guest support > is enabled but not Xen support, and only because Xen emulates HyperV but > does so incorrectly. > > This is a Xen bug, and as such it makes sense to reject Xen > specifically. If another hypervisor emulates HyperV and does so > correctly there seems to be no reason to reject it. I don't think so. AFAIK originally there were features exported as flags and Xen doesn't turn on the flags that correspond to features that are not implemented. The problem here is that Hyper-V is about to introduce a feature without a flag that is not implemented by Xen (see "X86: Deliver Hyper-V interrupts on a separate IDT vector"). K.Y. please confirm if I got this right. If I were the Microsoft engineer implementing this feature, no matter what Xen does or does not, I would also make sure that there is a corresponding flag for it, because in my experience they avoid future headaches. I wonder what happens if you run Linux with Hyper-V support on an old Hyper-V host that doesn't support vector injection. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
