search for: apicv

This patchset fixes some APICV issues, including a potential issue while doing live migration and enabling APICV while guest is in X2APIC mode. PATCH 1/2: Xen: Fix live migration while enabling APICV. PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling APICV.

SVI should be restored in case guest is processing virtual interrupt while saveing a domain state. Otherwise SVI would be missed when virtual interrupt delivery is enabled. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index ee2294c..38ff216 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@

...probably because we batch the used ring updating so tx interrupt may come randomly. We probably need to implement time bounded coalescing mechanism which could be configured from userspace. Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR regression on machine without APICv, (haven't found time to test APICv machine). But consider it was for correctness, I think it's acceptable? Then we can do optimization on top? Thanks > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 27 +++++++++++++++++++-----...

...probably because we batch the used ring updating so tx interrupt may come randomly. We probably need to implement time bounded coalescing mechanism which could be configured from userspace. Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR regression on machine without APICv, (haven't found time to test APICv machine). But consider it was for correctness, I think it's acceptable? Then we can do optimization on top? Thanks > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 27 +++++++++++++++++++-----...

...ot;APIC-register virtualization" and "virtual-interrupt deliver" VM-execution control has no effect on the behavior of RDMSR/WRMSR if the "virtualize x2APIC mode" VM-execution control is 0. When guest uses x2APIC mode, we should enable "virtualize x2APIC mode" for APICV first. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index de22e03..4807eb2 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -190,7 +190,8 @@ static int vmx_init_vmcs_config(void)...

...: Paolo Bonzini <pbonzini at redhat.com> >> CC: Roman Kagan <rkagan at virtuozzo.com> >> CC: Denis V. Lunev <den at openvz.org> >> CC: qemu-devel at nongnu.org >> CC: virtualization at lists.linux-foundation.org > Bad news. > > The test breaks with APICv, because of the following sequence of events: > > 1) non-auto-EOI interrupt 176 is injected into IRR and ISR > > 2) The PPR register is now 176 > > 3) auto-EOI interrupt 179 is injected into IRR only, because (179 & > 0xf0) <= (PPR & 0xf0) > > 4) interrupt 176...

...: Paolo Bonzini <pbonzini at redhat.com> >> CC: Roman Kagan <rkagan at virtuozzo.com> >> CC: Denis V. Lunev <den at openvz.org> >> CC: qemu-devel at nongnu.org >> CC: virtualization at lists.linux-foundation.org > Bad news. > > The test breaks with APICv, because of the following sequence of events: > > 1) non-auto-EOI interrupt 176 is injected into IRR and ISR > > 2) The PPR register is now 176 > > 3) auto-EOI interrupt 179 is injected into IRR only, because (179 & > 0xf0) <= (PPR & 0xf0) > > 4) interrupt 176...

...may not see the consumed packet in time. And the delay varies based on the workload since we count packets not bytes or time before doing the batched updating. Thanks > >> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >> regression on machine without APICv, (haven't found time to test APICv >> machine). But consider it was for correctness, I think it's acceptable? Then >> we can do optimization on top? >> >> >> Thanks >> >> >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >&...

...may not see the consumed packet in time. And the delay varies based on the workload since we count packets not bytes or time before doing the batched updating. Thanks > >> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >> regression on machine without APICv, (haven't found time to test APICv >> machine). But consider it was for correctness, I think it's acceptable? Then >> we can do optimization on top? >> >> >> Thanks >> >> >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >&...

...updating so tx interrupt may come >> randomly. We probably need to implement time bounded coalescing mechanism >> which could be configured from userspace. >> >> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >> regression on machine without APICv, (haven't found time to test APICv >> machine). But consider it was for correctness, I think it's acceptable? Then >> we can do optimization on top? >> >> >> Thanks >> >> >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >&...

...updating so tx interrupt may come >> randomly. We probably need to implement time bounded coalescing mechanism >> which could be configured from userspace. >> >> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >> regression on machine without APICv, (haven't found time to test APICv >> machine). But consider it was for correctness, I think it's acceptable? Then >> we can do optimization on top? >> >> >> Thanks >> >> >>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >&...

Hyper-V SynIC is a Hyper-V synthetic interrupt controller. The test runs on every vCPU and performs the following steps: * read from all Hyper-V SynIC MSR's * setup Hyper-V SynIC evt/msg pages * setup SINT's routing * inject SINT's into destination vCPU by 'hyperv-synic-test-device' * wait for SINT's isr's completion * clear Hyper-V SynIC evt/msg pages and destroy

Hyper-V SynIC is a Hyper-V synthetic interrupt controller. The test runs on every vCPU and performs the following steps: * read from all Hyper-V SynIC MSR's * setup Hyper-V SynIC evt/msg pages * setup SINT's routing * inject SINT's into destination vCPU by 'hyperv-synic-test-device' * wait for SINT's isr's completion * clear Hyper-V SynIC evt/msg pages and destroy

...t a time counter (or event byte counter) in vhost to add used and signal guest if it exceeds a value instead of waiting the number of packets. Thanks > >>>> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >>>> regression on machine without APICv, (haven't found time to test APICv >>>> machine). But consider it was for correctness, I think it's acceptable? Then >>>> we can do optimization on top? >>>> >>>> >>>> Thanks >>>> >>>> >>>>> S...

...t a time counter (or event byte counter) in vhost to add used and signal guest if it exceeds a value instead of waiting the number of packets. Thanks > >>>> Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR >>>> regression on machine without APICv, (haven't found time to test APICv >>>> machine). But consider it was for correctness, I think it's acceptable? Then >>>> we can do optimization on top? >>>> >>>> >>>> Thanks >>>> >>>> >>>>> S...

...atch the used ring updating so tx interrupt may come > randomly. We probably need to implement time bounded coalescing mechanism > which could be configured from userspace. > > Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR > regression on machine without APICv, (haven't found time to test APICv > machine). But consider it was for correctness, I think it's acceptable? Then > we can do optimization on top? > > > Thanks I don't see how it's for correctness to be frank. What if we just do the bulk free? Does that fix the reg...

...atch the used ring updating so tx interrupt may come > randomly. We probably need to implement time bounded coalescing mechanism > which could be configured from userspace. > > Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR > regression on machine without APICv, (haven't found time to test APICv > machine). But consider it was for correctness, I think it's acceptable? Then > we can do optimization on top? > > > Thanks > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > --- > > driver...

...gured from userspace. I don't think it's reasonable to expect userspace to be that smart ... Why do we need time bounded? used ring is always updated when ring becomes empty. > Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR > regression on machine without APICv, (haven't found time to test APICv > machine). But consider it was for correctness, I think it's acceptable? Then > we can do optimization on top? > > > Thanks > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > --- > > driver...

...me > > > randomly. We probably need to implement time bounded coalescing mechanism > > > which could be configured from userspace. > > > > > > Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR > > > regression on machine without APICv, (haven't found time to test APICv > > > machine). But consider it was for correctness, I think it's acceptable? Then > > > we can do optimization on top? > > > > > > > > > Thanks > > > > > > > > > > Signed-off-b...

...start flowing again. It might be suboptimal, we might need to tune it but I doubt running timers is a solution, timer interrupts cause VM exits. > > > > > > Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR > > > regression on machine without APICv, (haven't found time to test APICv > > > machine). But consider it was for correctness, I think it's acceptable? Then > > > we can do optimization on top? > > > > > > > > > Thanks > > > > > > > > > > Signed-off-b...