Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

On Mon, Aug 08, 2016 at 04:57:14PM +0800, Peter Xu wrote: >On Mon, Aug 08, 2016 at 03:41:23PM +0800, Chao Gao wrote: >> HI, everyone. >> >> We have done some tests after merging this patch set into the lastest qemu >> master. In kvm aspect, we use the lastest

Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

On Mon, Aug 08, 2016 at 11:18:20AM +0200, Igor Mammedov wrote: >On Mon, 8 Aug 2016 15:41:23 +0800 >Chao Gao <chao@intel.com> wrote: > >> HI, everyone. >> >> We have done some tests after merging this patch set into the lastest qemu >> master. In kvm as

Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

On Tue, Aug 09, 2016 at 02:18:15PM +0800, Peter Xu wrote: >On Tue, Aug 09, 2016 at 12:33:17PM +0800, Chao Gao wrote: >> On Mon, Aug 08, 2016 at 04:57:14PM +0800, Peter Xu wrote: >> >On Mon, Aug 08, 2016 at 03:41:23PM +0800, Chao Gao wrote: >> >> HI, everyone. >&g

Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

nel code bases, I couldn't find some patches to solve them. Will you fix these problems or leave them to communities? Thanks, -Chao On Tue, Aug 09, 2016 at 02:51:16PM +0200, Radim Krčmář wrote: >2016-08-09 16:19+0800, Chao Gao: >> On Tue, Aug 09, 2016 at 02:18:15PM +0800, Peter Xu wrote

Re: [Qemu-devel] [PATCH v5 0/3] IOMMU: intel_iommu support map and unmap notifications

On Fri, Oct 21, 2016 at 12:07:18AM +0300, Aviv B.D wrote: >From: "Aviv Ben-David" > >* Advertize Cache Mode capability in iommu cap register. > This capability is controlled by "cache-mode" property of intel-iommu device. > To enable this option call QEMU with "-device

Re: [Qemu-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

On Thu, Mar 30, 2017 at 06:29:29PM +0100, Anthony PERARD wrote: >On Fri, Mar 17, 2017 at 07:29:17PM +0800, Lan Tianyu wrote: >> From: Chao Gao <chao@intel.com> >> Subject: msi: taking interrupt format into consideration during >> judging a pirq is binded with a eve

Re: [Qemu-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

On Thu, Mar 30, 2017 at 05:51:45PM +0100, Anthony PERARD wrote: >On Fri, Mar 17, 2017 at 07:29:16PM +0800, Lan Tianyu wrote: >> From: Chao Gao <chao@intel.com> >> >> If a vIOMMU is exposed to guest, guest will configure the msi to remapping >> format.

Re: [Qemu-devel] [RFC PATCH 2/4] Xen: add a dummy vIOMMU to create/destroy vIOMMU in Xen

On Thu, Mar 30, 2017 at 05:24:52PM +0100, Anthony PERARD wrote: >Hi, > >On Fri, Mar 17, 2017 at 07:29:15PM +0800, Lan Tianyu wrote: >> From: Chao Gao <chao@intel.com> >> >> Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE >> as p

Re: [Qemu-devel] [PATCH v3 1/3] i386/msi: Correct mask of destination ID in MSI address

On Fri, Nov 17, 2017 at 03:24:21PM +0200, Michael S. Tsirkin wrote: >On Fri, Nov 17, 2017 at 02:24:23PM +0800, Chao Gao wrote: >> According to SDM 10.11.1, only [19:12] bits of MSI address are >> Destination ID, change the mask to avoid ambiguity for VT-d spec >> has used

[Qemu-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen

filtering. The main reason why we want this is QEMU doesn't have the knowledge to decide the interrupt format after we introduce vIOMMU inside Xen. Passing the whole msi message down and let arch-specific vIOMMU to decide the interrupt format. Signed-off-by: Chao Gao <chao@intel.com> Sign

[Qemu-devel] [PATCH v3 1/3] i386/msi: Correct mask of destination ID in MSI address

According to SDM 10.11.1, only [19:12] bits of MSI address are Destination ID, change the mask to avoid ambiguity for VT-d spec has used the bit 4 to indicate a remappable interrupt request. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com&

[Qemu-devel] [PATCH v3 0/3] Qemu: add Xen vIOMMU interrupt remapping function support

, the exist interface is modified to support msi of both format. - In patch 3, define MSI_ADDR_IF_MASK inside a function because it is intel-specific. It is improper to define it in a common header. Chao Gao (3): i386/msi: Correct mask of destination ID in MSI address xen/pt: Pass the whole msi addr/data

[Qemu-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request

a pirq. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- v3: - clarify the interrupt format bit is Intel-specific, then it is improper to define MSI_ADDR_IF_MASK in a common header. --- hw/i386/xen/xen-hvm.c | 10 +- hw/pci/msi.c

Re: [Qemu-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen

On Mon, Dec 11, 2017 at 05:59:08PM +, Anthony PERARD wrote: >On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote: >> Previously, some fields (reserved or unalterable) are filtered by >> Qemu. This fields are useless for the legacy interrupt format. >> However,

Re: [Qemu-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request

On Mon, Dec 11, 2017 at 06:07:48PM +, Anthony PERARD wrote: >On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote: >> According to VT-d spec Interrupt Remapping and Interrupt Posting -> >> Interrupt Remapping -> Interrupt Request Formats On Intel 64 >> Pl

[Qemu-devel] [RFC Patch] xen/pt: Emulate FLR capability

guest, deleting emulated registers), then initiate PCI reset through 'reset' knob under the device's sysfs, finally initialize the device again. Signed-off-by: Chao Gao --- Do we need to introduce an attribute, like "permissive" to explicitly enable FLR capability emulation? During

Re: [Qemu-devel] [RFC Patch] xen/pt: Emulate FLR capability

On Thu, Aug 29, 2019 at 12:03:44PM +0200, Jan Beulich wrote: >On 29.08.2019 11:02, Chao Gao wrote: >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's >> perspective, assigned devices cannot be reset. But some devices rely on PCI >> reset to recove

Re: [Qemu-devel] [RFC Patch] xen/pt: Emulate FLR capability

On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote: >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote: >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's >> perspective, assigned devices cannot be reset. But some devices rely

Re: [PATCH] vhost: use large iotlb entry if no IOMMU translation is needed

Ping. Could someone help to review this patch? Thanks Chao On Wed, Jul 21, 2021 at 03:54:02PM +0800, Chao Gao wrote: >If guest enables IOMMU_PLATFORM for virtio-net, severe network >performance drop is observed even if there is no IOMMU. And disabling >vhost can mitigate the perf issue

Re: [PATCH] vhost: use large iotlb entry if no IOMMU translation is needed

On Tue, Aug 03, 2021 at 12:43:58PM +0800, Jason Wang wrote: > >在 2021/8/3 下午12:29, Chao Gao 写道: >> Ping. Could someone help to review this patch? >> >> Thanks >> Chao >> >> On Wed, Jul 21, 2021 at 03:54:02PM +0800, Chao Gao wrote: >> > If

Re: [PATCH 0/3] Disable vhost device IOTLB is IOMMU is not enabled

> >So patch tries to use transport specific method to detect the enalbing >of vIOMMU and enable the device IOTLB only if vIOMMU is enalbed. > >Please review. Tested-by: Chao Gao Tested with TDX; this series fixes the performance issue we saw in a TD when vhost was enabled. Thanks

[PATCH] vhost: use large iotlb entry if no IOMMU translation is needed

ion where the iova resides as a large iotlb entry. Signed-off-by: Chao Gao --- hw/virtio/vhost.c | 6 +++--- include/exec/memory.h | 16 ++-- softmmu/physmem.c | 37 + 3 files changed, 46 insertions(+), 13 deletions(-) diff --git a/hw/vir

Re: [RFC] KVM / QEMU: Introduce Interface for Querying APICv Info

On Fri, May 20, 2022 at 10:30:40AM +0700, Suthikulpanit, Suravee wrote: >Hi All, > >Currently, we don't have a good way to check whether APICV is active on a VM. >Normally, For AMD SVM AVIC, users either have to check for trace point, or >using >"perf kvm stat live" to catch AVIC-related #VMEXIT.

Re: [RFC v1] util/aio: Keep notification disabled as much as possible

>fdmon_ops->need_wait(ctx)) { >+if (poll_set_started(ctx, _list, false)) { >+timeout = 0; >+progress = true; In this case, is it ok to skip the call of ->wait() below? If yes, maybe put the call in the "else" path. >+} >+ >

[RFC v1] util/aio: Keep notification disabled as much as possible

151 3.60% 2.79% 0.40us 52.07us 1.30us ( +- 31.44% ) Signed-off-by: Chao Gao --- util/aio-posix.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/util/aio-posix.c b/util/aio-posix.c index 731f3826c0..bd2076145b 100644 --- a/util/aio-posix.c ++

[PATCH] util/aio: Defer disabling poll mode as long as possible

guest, defer disabling poll mode to when the event loop is about to be blocked. With this patch applied, FIO seq-read performance (bs=4k, iodepth=64, cache=writethrough) in VMs increases from 330K/s to 413K/s IOPS. Suggested-by: Stefan Hajnoczi Signed-off-by: Chao Gao --- util/aio-posix.c | 21

Re: [RFC v1] util/aio: Keep notification disabled as much as possible

On Wed, Jul 06, 2022 at 12:59:29PM +0100, Stefan Hajnoczi wrote: >On Fri, Jul 01, 2022 at 05:13:48PM +0800, Chao Gao wrote: >> When measuring FIO read performance (cache=writethrough, bs=4k, iodepth=64) >> in >> VMs, we observe ~80K/s notifications (e.g., EPT_MISCONFIG) f

Re: [QEMU PATCH] x86: Set maximum APIC ID to KVM prior to vCPU creation

On Fri, May 20, 2022 at 02:39:28PM +0800, Zeng Guang wrote: >Specify maximum possible APIC ID assigned for current VM session prior to >the creation of vCPUs. KVM need set up VM-scoped data structure indexed by >the APIC ID, e.g. Posted-Interrupt Descriptor table to support Intel IPI