On Fri, Dec 08, 2017 at 11:49:57AM +0100, Vitaly Kuznetsov wrote: > -----Original Message----- > From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > Sent: Friday, December 8, 2017 2:50 AM > To: kvm@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>; Radim Krčmář <rkrcmar@xxxxxxxxxx>; Thomas > Gleixner <tglx@xxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; H. Peter Anvin > <hpa@xxxxxxxxx>; KY Srinivasan <kys@xxxxxxxxxxxxx>; Haiyang Zhang > <haiyangz@xxxxxxxxxxxxx>; Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>; Michael > Kelley (EOSG) <Michael.H.Kelley@xxxxxxxxxxxxx>; Andy Lutomirski <luto@xxxxxxxxxx>; > Mohammed Gamal <mmorsy@xxxxxxxxxx>; Cathy Avery <cavery@xxxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx > Subject: [PATCH 3/6] x86/hyper-v: reenlightenment notifications support > > Hyper-V supports Live Migration notification. This is supposed to be used in conjunction with > TSC emulation: when we are migrated to a host with different TSC frequency for some short > period host emulates our accesses to TSC and sends us an interrupt to notify about the event. > When we're done updating everything we can disable TSC emulation and everything will start > working fast again. > > We didn't need these notifications before as Hyper-V guests are not supposed to use TSC as a > clocksource: in Linux we even mark it as unstable on boot. Guests normally use 'tsc page' > clocksouce and host updates its values on migrations automatically. > > Things change when we want to run nested virtualization: even when we pass through PV > clocksources (kvm-clock or tsc page) to our guests we need to know TSC frequency and when it > changes. > > Hyper-V Top Level Functional Specification (as of v5.0b) wrongly specifies > EAX:BIT(12) of CPUID:0x40000009 as the feature identification bit. The right one to check is > EAX:BIT(13) of CPUID:0x40000003. I was assured that the fix in on the way. > > Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> [snip] > diff --git a/arch/x86/include/asm/irq_vectors.h > b/arch/x86/include/asm/irq_vectors.h > index 67421f649cfa..e71c1120426b 100644 > --- a/arch/x86/include/asm/irq_vectors.h > +++ b/arch/x86/include/asm/irq_vectors.h > @@ -103,7 +103,12 @@ > #endif > > #define MANAGED_IRQ_SHUTDOWN_VECTOR 0xef > -#define LOCAL_TIMER_VECTOR 0xee > + > +#if IS_ENABLED(CONFIG_HYPERV) > +#define HYPERV_REENLIGHTENMENT_VECTOR 0xee > +#endif > + > +#define LOCAL_TIMER_VECTOR 0xed > > #define NR_VECTORS 256 [snip] Since you are pre-allocating a new vector, would you want to update the irq_cpustat_t data structure and your interrupt handler to count the occurrences of these interrupts, and update arch_show_interrupts() to show the count? Then cat /proc/interrupts will show the count. The reenlightenment interrupts will presumably be rare, but so are some of the others that are already counted and displayed, and it seems like consistency should be maintained. Michael _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
