Re: [Qemu-devel] [PATCH 5/5] intel_iommu: do not allow EIM without KVM support

2016-09-23 11:27+0200, Paolo Bonzini: > Since the whole IOMMU feature is new and somewhat experimental, I think > it's okay to just make EIM the default for >=2.8 machine types if KVM is > on (using DEFINE_PROP_ON_OFF_AUTO; auto means true if KVM is on and Sounds good. > false otherwise, and

Re: [Qemu-devel] [PATCH 2/5] apic: add send_msi() to APICCommonClass

2016-09-26 14:38+0200, Igor Mammedov: > On Thu, 22 Sep 2016 23:04:29 +0200 > Radim Krčmář <rkrc...@redhat.com> wrote: > >> The MMIO based interface to APIC doesn't work well with MSIs that have >> upper address bits set (remapped x2APIC MSIs). A specialized interface

Re: [Qemu-devel] [PATCH 3/5] intel_iommu: pass whole remapped addresses to apic

2016-09-23 17:41+0800, Peter Xu: > On Thu, Sep 22, 2016 at 11:04:30PM +0200, Radim Krčmář wrote: > > [...] > >> @@ -279,18 +280,16 @@ static void vtd_update_iotlb(IntelIOMMUState *s, >> uint16_t source_id, >> static void vtd_generate_interrupt(IntelIOMMU

Re: [Qemu-devel] [PATCH 1/5] apic: add global apic_get_class()

2016-09-23 17:17+0800, Peter Xu: > On Thu, Sep 22, 2016 at 11:04:28PM +0200, Radim Krčmář wrote: >> Every configuration has only up to one APIC class and we'll be extending >> the class with a function that can be called without an instanced >> object, so a direct access to th

[Qemu-devel] [PATCH 2/5] apic: add send_msi() to APICCommonClass

The MMIO based interface to APIC doesn't work well with MSIs that have upper address bits set (remapped x2APIC MSIs). A specialized interface is a quick and dirty way to avoid the shortcoming. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/i386/kvm/apic.c

Re: [Qemu-devel] [PATCH v2 10/14] pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode

2016-09-22 16:36+0200, Paolo Bonzini: > On 22/09/2016 14:50, Igor Mammedov wrote: >> +#ifdef KVM_CAP_X2APIC_API >> +if (kvm_check_extension(s, KVM_CAP_X2APIC_API)) { >> +has_x2apic_ids = !kvm_vm_enable_cap(s, KVM_CAP_X2APIC_API, 0, >> +

[Qemu-devel] [PATCH 5/5] intel_iommu: do not allow EIM without KVM support

Cluster x2APIC cannot work without KVM's x2apic API when the maximal APIC ID is > 8. Make the code simpler by completely forbidding EIM without KVM's x2apic API. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- I think it the dependency would be nicer in the eim setter, but th

[Qemu-devel] [PATCH 0/5] intel_iommu: fix EIM

"eim" property Radim Krčmář (4): apic: add global apic_get_class() apic: add send_msi() to APICCommonClass intel_iommu: pass whole remapped addresses to apic intel_iommu: do not allow EIM without KVM support hw/i386/intel_iommu.c | 41 +--

[Qemu-devel] [PATCH 4/5] intel_iommu: add "eim" property

From: Peter Xu Adding one extra property for intel-iommu device to decide whether we should support EIM bit for IR. Now we are throwing high 24 bits of dest_id away directly. This will cause interrupt issues with guests that: - enabled x2apic with cluster mode - have more

[Qemu-devel] [PATCH 1/5] apic: add global apic_get_class()

Every configuration has only up to one APIC class and we'll be extending the class with a function that can be called without an instanced object, so a direct access to the class is convenient. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/intc/apic_common.c

[Qemu-devel] [PATCH 3/5] intel_iommu: pass whole remapped addresses to apic

. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/i386/intel_iommu.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 28c31a2cdfa3..1a0961e5cf6a 100644 --- a/hw/i386/intel_iommu.c +++ b/h

[Qemu-devel] [PATCH] build: handle deprecation of major() in sys/types.h

macro `major', you should #undef it after including . Include for all users of . Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- include/qemu/osdep.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h index 9e9fa6154642..fad31c3d5b56

Re: [Qemu-devel] [PATCH] pc: apic: fix touch LAPIC when irqchip is split

or PIC, > so pic_read_irq() would return 15, thinking it was spurious. > > This patch fix it by don't touch LAPIC if LAPIC is in kernel. > > Suggested-by: Paolo Bonzini <pbonz...@redhat.com> > Suggested-by: Radim Krčmář <rkrc...@redhat.com> > Cc: Paolo Bonzini <pbonz

Re: [Qemu-devel] [PATCH] pc: apic: fix touch LAPIC when irqchip is split

2016-09-14 16:02+0200, Radim Krčmář: > Reviewed-by: Radim Krčmář <rkrc...@redhat.com> > > (The code is horribly tangled, so I might have missed something.) This reply should have went for the v2, sorry.

Re: [Qemu-devel] [PATCH v2] pc: apic: fix touch LAPIC when irqchip is split

or PIC, > so pic_read_irq() would return 15, thinking it was spurious. > > This patch fix it by don't touch LAPIC if LAPIC is in kernel. > > Suggested-by: Paolo Bonzini <pbonz...@redhat.com> > Suggested-by: Radim Krčmář <rkrc...@redhat.com> > Cc: Paolo Bonzini <pbonz

Re: [Qemu-devel] [PATCH] intel_iommu: add "eim" property

2016-08-11 21:29+0800, Peter Xu: > Adding one extra property for intel-iommu device to decide whether we > should support EIM bit for IR. > > Now we are throwing high 24 bits of dest_id away directly. This will > cause interrupt issues with guests that: > > - enabled x2apic with cluster mode > -

Re: [Qemu-devel] [PATCH 2/2] intel-iommu: restrict EIM to quirkless KVM

2016-08-10 11:29+0800, Peter Xu: > On Tue, Aug 09, 2016 at 05:03:33PM +0200, Radim Krčmář wrote: >> APIC in QEMU doesn't support x2APIC so exposing EIM is pointless and KVM >> has a quirk that needs to be disabled unless we want x2APIC message with >> destination 0xff

Re: [Qemu-devel] [PATCH] checkpatch: allow tabs in linux-headers

porting. >> > >> > Signed-off-by: Radim Krčmář <rkrc...@redhat.com> >> > --- >> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl >> > index 929708721299..38232d4b25c3 100755 >> > --- a/scripts/checkpatch.pl >> > +++

[Qemu-devel] [PATCH] checkpatch: ignore automatically imported Linux headers

Linux uses tabs for indentation and checkpatch always complained about automatically imported headers. update-linux-headers.sh could be modified to expand tabs, but there is no real reason to complain about any ugly code in Linux headers, so skip all hunk-related checks. Signed-off-by: Radim

Re: [Qemu-devel] [PATCH] checkpatch: allow tabs in linux-headers

2016-08-09 18:39+0200, Paolo Bonzini: > On 09/08/2016 18:37, Radim Krčmář wrote: >>>> Make scripts/checkpatch.pl accept tabs in linux-headers/, instead of >>>> changing scripts/update-linux-headers.sh to expand tabs when importing. >>>> >>>&

Re: [Qemu-devel] [PATCH] checkpatch: allow tabs in linux-headers

>> Make scripts/checkpatch.pl accept tabs in linux-headers/, instead of >> changing scripts/update-linux-headers.sh to expand tabs when importing. >> >> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> >> --- >> diff --git a/scripts/checkpatch.pl b/s

Re: [Qemu-devel] [PATCH 1/2] linux-headers: update to v4.8-rc1

2016-08-09 17:03+0200, Radim Krčmář: > Signed-off-by: Radim Krčmář <rkrc...@redhat.com> > --- > linux-headers/linux/kvm.h | 18 -- This patch did not update all headers. v2 will have include/standard-headers/linux/input-event-codes.h | 32 + i

[Qemu-devel] [PATCH] checkpatch: allow tabs in linux-headers

> > total: 9 errors, 0 warnings, 51 lines checked > > Your patch has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. These indentation errors are false positives. ---8<--- Mak

[Qemu-devel] [PATCH 1/2] linux-headers: update to v4.8-rc1

Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- linux-headers/linux/kvm.h | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h index e60e21ba227e..4806e069e749 100644 --- a/linux-headers/linux

[Qemu-devel] [PATCH for-2.7 0/2] intel-iommu: restrict EIM to quirkless KVM

EIM should have been disabled because it doesn't work with KVM nor QEMU APIC. This series proposes a way to keep it enabled on KVM v4.8+. (Xen is silently ignored.) Radim Krčmář (2): linux-headers: update to v4.8-rc1 intel-iommu: restrict EIM to quirkless KVM hw/i386/intel_iommu.c | 10

[Qemu-devel] [PATCH 2/2] intel-iommu: restrict EIM to quirkless KVM

APIC in QEMU doesn't support x2APIC so exposing EIM is pointless and KVM has a quirk that needs to be disabled unless we want x2APIC message with destination 0xff to be misinterpreted as a broadcast. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/i386/intel_iommu.c

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

2016-08-09 16:19+0800, Chao Gao: > 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.

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

2016-08-09 15:09+0800, Peter Xu: > On Tue, Aug 09, 2016 at 08:33:13AM +0200, Jan Kiszka wrote: >> On 2016-08-09 08:24, Peter Xu wrote: >> > 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

Re: [Qemu-devel] [PATCH v4 09/16] apic: drop APICCommonState.idx and use APIC ID as index in local_apics[]

one as we have higher chance of hitting the correct apic in local_apics[]. Reviewed-by: Radim Krčmář <rkrc...@redhat.com> > CC: Radim Krčmář <rkrc...@redhat.com> > CC: pbonz...@redhat.com > --- > include/hw/i386/apic_internal.h | 1 - > hw/intc/apic.c

Re: [Qemu-devel] [PATCH v4 08/16] apic: move MAX_APICS check to 'apic' class

ore then MAX_APICS. > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > --- The other two APIC implementations, for KVM a Xen, don't seem to need this extra check. Reviewed-by: Radim Krčmář <rkrc...@redhat.com> > CC: Radim Krčmář <rkrc...@redhat.com> &g

Re: [Qemu-devel] [PATCH v11 00/28] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-07-08 18:36+0200, Paolo Bonzini: > On 08/07/2016 18:01, Radim Krčmář wrote: >> The patchset doesn't work with if you have 16 APICs with IDs 0-15 and >> then some more, because KVM has hacked x2APIC support that translates >> logical interrupt with destination 0xff (firs

Re: [Qemu-devel] [PATCH v11 00/28] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-07-05 16:19+0800, Peter Xu: > This is v11 of Intel IR work. It is rebased to mst's branch > "tags/for_upstream", commit: > > "278a2a2 vmw_pvscsi: remove unnecessary internal msi state flag" > > This series mainly fixed several issues in v10 review comments, fixed > one bug with RHEL

Re: [Qemu-devel] [PATCH v3 1/2] target-i386: KVM: add basic Intel LMCE support

2016-06-03 14:09+0800, Haozhong Zhang: > This patch adds the support to inject SRAR and SRAO as LMCE, i.e. they > will be injected to only one VCPU rather than broadcast to all > VCPUs. As KVM reports LMCE support on Intel platforms, this features is > only available on Intel platforms. > >

Re: [Qemu-devel] [PATCH v2] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

2016-05-12 19:15+0200, Radim Krčmář: > I looked at a dozen Intel CPU that have this CPUID and all of them > always had Core offset as 1 (a wasted bit when hyperthreading is > disabled) and Package offset at least 4 (wasted bits at <= 4 cores). > > QEMU uses more compact IDs a

[Qemu-devel] [PATCH v3] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

SMT and Core sub-leaves even if there is just one thread/core; it makes the code simpler and there should be no harm. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- This patch depends on Igor's "pc: add 2.7 machine". v2: * assert *eax instead of silently masking [E

[Qemu-devel] [PATCH v2] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

SMT and Core sub-leaves even if there is just one thread/core; it makes the code simpler and there should be no harm. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- This patch depends on Igor's "pc: add 2.7 machine". v2: * assert *eax instead of silently masking [E

Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

2016-05-11 12:26-0300, Eduardo Habkost: > On Wed, May 11, 2016 at 02:37:38PM +0200, Radim Krčmář wrote: >> 2016-05-10 16:53-0300, Eduardo Habkost: >> > On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote: >> >> I looked at a dozen Intel CPU that h

Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

2016-05-10 16:53-0300, Eduardo Habkost: > On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote: >> I looked at a dozen Intel CPU that have this CPUID and all of them >> always had Core offset as 1 (a wasted bit when hyperthreading is >> disabled) and Package offset at

Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

2016-05-09 22:49+0200, Radim Krčmář: > I looked at a dozen Intel CPU that have this CPUID and all of them > always had Core offset as 1 (a wasted bit when hyperthreading is > disabled) and Package offset at least 4 (wasted bits at <= 4 cores). > > QEMU uses more compact IDs a

[Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

SMT and Core sub-leaves even if there is just one thread/core; it makes the code simpler and there should be no harm. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- target-i386/cpu.c | 27 +++ target-i386/cpu.h | 5 + 2 files changed, 32 insertions(+) d

Re: [Qemu-devel] [PATCH v6 00/26] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-05-09 19:15+0200, Radim Krčmář: > From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrc...@redhat.com> > Date: Mon, 9 May 2016 19:04:56 +0200 > Subject: [PATCH] intel_iommu: support all masks in interrupt entry cache > invalidation > > Linux guests do not grac

Re: [Qemu-devel] [PATCH v6 00/26] IOMMU: Enable interrupt remapping for Intel IOMMU

x guests do not gracefully handle cases when the invalidation mask they wanted is not supported, probably because real hardware always allowed all. We can just say that all 16 masks are supported, because both ioapic_iec_notifier and kvm_update_msi_routes_all invalidate all caches. Signed-off-by: Radim K

Re: [Qemu-devel] [PATCH 4/4] kvm: support MSI_X2APIC capability

2016-05-07 16:03+0200, Jan Kiszka: > On 2016-05-06 22:53, Radim Krčmář wrote: >> The capability alows us to express x2APIC destinations. > > "allows" Thanks. :) > Will the possibility to create >254 CPUs be indirectly coupled to this > capability, or shoul

Re: [Qemu-devel] [RFC 0/4] APIC, IOMMU, KVM: add x2APIC interface

2016-05-09 13:36+0800, Peter Xu: > On Fri, May 06, 2016 at 10:53:44PM +0200, Radim Krčmář wrote: >> This series bases on Peter's IR v6 and depends on patches that were just >> posted to kvm-list, "[RFC 0/9] KVM: x86: break the xAPIC barrier". >> >> The ker

[Qemu-devel] [PATCH 3/4] linux_headers: add MSI_X2APIC

Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- linux-headers/linux/kvm.h | 5 + 1 file changed, 5 insertions(+) diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h index 3bae71a8743e..3d9ca622bec9 100644 --- a/linux-headers/linux/kvm.h +++ b/linux-headers/linux

[Qemu-devel] [PATCH 4/4] kvm: support MSI_X2APIC capability

The capability alows us to express x2APIC destinations. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- include/sysemu/kvm.h | 1 + kvm-all.c| 14 +- target-i386/kvm.c| 4 3 files changed, 18 insertions(+), 1 deletion(-) diff --git a/include/sysemu

[Qemu-devel] [RFC 0/4] APIC, IOMMU, KVM: add x2APIC interface

were being delivered to both of them, but level didn't work -- only one interrupt was ever delivered, I blame EOI. I didn't have enough time to look into IR, but will do so next week. Radim Krčmář (4): apic: add deliver_msi to APICCommonClass intel_iommu: use deliver_msi APIC callback linux_he

[Qemu-devel] [PATCH 1/4] apic: add deliver_msi to APICCommonClass

that delivers extended MSIs This patch uses latter option, because it was easier for me, but I think the former one could be a tad nicer. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/i386/kvm/apic.c | 21 ++--- hw/i386/xen/xen_apic.c | 7 +

[Qemu-devel] [PATCH 2/4] intel_iommu: use deliver_msi APIC callback

The memory-mapped interface cannot express x2APIC destinations that are a result of remapping. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- hw/i386/intel_iommu.c | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/hw/i386/intel_iommu.

Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-28 17:18+0800, Peter Xu: > On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote: >> Instead of fiddling with irq routes for the IOAPIC - where we don't need >> it -, I would suggest to do the following: Send IOAPIC events via >> kvm_irqchip_send_msi to the kernel. Only irqfd users

Re: [Qemu-devel] [PATCH v5 18/18] ioapic: clear remote irr bit for edge-triggered interrupts

failed to work when IR enabled (tested with Linux > kernel version 4.5). > > Signed-off-by: Peter Xu <pet...@redhat.com> > --- Reviewed-by: Radim Krčmář <rkrc...@redhat.com>

Re: [Qemu-devel] [PATCH v5 17/18] ioapic: keep RO bits for IOAPIC entry

2016-04-28 15:05+0800, Peter Xu: > Currently IOAPIC RO bits can be written. To be better aligned with > hardware, we should let them read-only. > > Signed-off-by: Peter Xu <pet...@redhat.com> > --- Reviewed-by: Radim Krčmář <rkrc...@redhat.com>

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-28 13:27+0800, Peter Xu: > On Wed, Apr 27, 2016 at 04:31:13PM +0200, Radim Krčmář wrote: > > [...] > >> >> > I am still looking into guest part codes. Although the above patch >> >> > should solve the issue, there are still issues

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-27 15:29+0800, Peter Xu: > On Tue, Apr 26, 2016 at 04:19:00PM +0200, Radim Krčmář wrote: >> 2016-04-26 15:34+0800, Peter Xu: >> > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c >> > @@ -281,6 +281,36 @@ ioapic_mem_read(void *opaque, hwaddr ad

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-26 17:28+0200, Jan Kiszka: > On 2016-04-26 16:59, Radim Krčmář wrote: >> 2016-04-26 16:24+0200, Jan Kiszka: >>> On 2016-04-26 13:40, Peter Xu wrote: >>>> Currently, all the interrupts will be translated into one MSI in >>>> vtd_generate_msi_

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-26 16:24+0200, Jan Kiszka: > On 2016-04-26 13:40, Peter Xu wrote: >> Currently, all the interrupts will be translated into one MSI in >> vtd_generate_msi_message(), in which only 8 bits of dest_id is used >> (msg.dest = irq->dest). We may possibly need to use the high 32 bits >> of MSI

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-26 15:34+0800, Peter Xu: > Hi, Jan, > > The above issue should be caused by EOI missing of level-triggered > interrupts. Before that, I was always using edge-triggered > interrupts for test, so didn't encounter this one. Would you please > help try below patch? It can be applied directly

Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-04-25 09:24+0200, Jan Kiszka: > On 2016-04-25 09:18, Peter Xu wrote: >> On Mon, Apr 25, 2016 at 07:16:19AM +0200, Jan Kiszka wrote: >>> On 2016-04-19 10:38, Peter Xu wrote: - EIM support >>> >>> That should be fairly easy, I already played with it (hack in EIM cap, >>> change

Re: [Qemu-devel] [PATCH] target-i386: add AMD CPUID.1:edx aliases to x86_cpu_get_migratable_flags

2016-04-15 13:54-0300, Eduardo Habkost: > On Thu, Apr 14, 2016 at 10:55:07PM +0200, Radim Krčmář wrote: >> QEMU complains about -cpu host on an AMD machine: >> warning: host doesn't support requested feature: CPUID.8001H:EDX [bit >> 0] >> For bits 0,1,3,4,5,6,7,

Re: [Qemu-devel] [PATCH v3 12/13] q35: ioapic: add support for split irqchip and irqfd

2016-04-15 11:31+0800, Peter Xu: > This patch allows Intel IR work with splitted irqchip. Two more fields > are added to IOAPICCommonState to support the translation process (For > future AMD IR support, we will need to provide another AMD-specific > callback for int_remap()). In split irqchip

[Qemu-devel] [PATCH] target-i386: add AMD CPUID.1:edx aliases to x86_cpu_get_migratable_flags

realizing that they are aliases to CPUID.1H:EDX and have their names there. See https://bugzilla.redhat.com/show_bug.cgi?id=1326721 for details. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- target-i386/cpu.c | 40 ++-- 1 file changed, 22 insertions(

Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-02-19 07:46+0100, Jan Kiszka: > - Rita Sinha is currently working on integrating my old patches with the > split-irqchip to get KVM working (as an Outreachy project). It's > probably a bit unfortunate to consider a different horse that late in to > project. What do you think, how could we

Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU

2016-02-19 12:43+0100, Jan Kiszka: > On 2016-02-19 12:34, Peter Xu wrote: >> On Fri, Feb 19, 2016 at 10:58:12AM +0100, Paolo Bonzini wrote: >>> >>> The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. >> >> I see that MemTxAttrs is not enabled yet? It's dropped in all the >>

Re: [Qemu-devel] [PATCH] copy, dd: simplify and optimize NUL bytes detection

2015-10-22 18:14+0200, Paolo Bonzini: > On 22/10/2015 18:02, Eric Blake wrote: >> I see a bug in there: > > Of course. You shouldn't have told me what the bug was, I deserved > to look for it myself. :) It rather seems that you don't want spoilers, :) I see two bugs now. > bool

Re: [Qemu-devel] Help debugging a regression in KVM Module

2015-08-18 16:54+0200, Peter Lieven: After some experiments I was able to find out the bad commit that introduced the regression: commit f30ebc312ca9def25650b4e1d01cdb425c310dca Author: Radim Krčmář rkrc...@redhat.com Date: Thu Oct 30 15:06:47 2014 +0100 It seems

[Qemu-devel] [PATCH for-2.4] target-i386: fix IvyBridge xlevel in PC_COMPAT_2_3

Previous patch changed xlevel and missed the compatibility code. Fixes: 3046bb5debc8 (target-i386: emulate CPUID level of real hardware) Signed-off-by: Radim Krčmář rkrc...@redhat.com --- include/hw/i386/pc.h | 4 1 file changed, 4 insertions(+) diff --git a/include/hw/i386/pc.h b/include

[Qemu-devel] [PATCH v3 3/3] crypto: use CPP for wrapper definitions in nettle

It's horrible both ways and I prefer this one. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- v3: make wrappers 'static' v2: new crypto/cipher-nettle.c | 47 +-- 1 file changed, 17 insertions(+), 30 deletions(-) diff --git a/crypto/cipher

[Qemu-devel] [PATCH v3 2/3] crypto: avoid undefined behavior in nettle calls

won't be done if we drop argument's true type and pointers can have different sizes so passing arguments on stack would bug.) Having two different prototypes based on nettle version doesn't make this solution any nicer. Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Radim

[Qemu-devel] [PATCH v3 0/3] crypto: nettle fixes

behavior[2-3/3] Radim Krčmář (3): crypto: fix build with nettle = 3.0.0 crypto: avoid undefined behavior in nettle calls crypto: use CPP for wrapper definitions in nettle configure | 4 +++- crypto/cipher-nettle.c | 38 -- 2 files changed, 35

[Qemu-devel] [PATCH v3 1/3] crypto: fix build with nettle = 3.0.0

versions. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- v3: no change v2: fix typo in crypto configure | 4 +++- crypto/cipher-nettle.c | 16 ++-- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 33b945530e64..cc0338ddbd14

Re: [Qemu-devel] [PATCH v2 2/3] crypto: avoid undefined behavior in nettle calls

2015-07-10 19:18+0200, Radim Krčmář: diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c +void aes_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length, + uint8_t *dst, const uint8_t *src) Wrappers should be static (rushed posting). I'll send v3 on Wed/Thu

[Qemu-devel] [PATCH] crypt: fix build with nettle = 3.0.0

versions. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- I don't know if we want to kill the #if compatibility after a while (so QEMU doesn't become glibc-like) -- I could split this patch into two, where the first one would just be reverted. configure | 4 +++- crypto/cipher

Re: [Qemu-devel] [PATCH] crypt: fix build with nettle = 3.0.0

2015-07-10 13:56+0100, Peter Maydell: On 10 July 2015 at 13:33, Radim Krčmář rkrc...@redhat.com wrote: @@ -83,8 +87,8 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg, -ctx-alg_encrypt = (nettle_crypt_func *)des_encrypt; -ctx-alg_decrypt = (nettle_crypt_func

Re: [Qemu-devel] [PATCH] crypt: fix build with nettle = 3.0.0

2015-07-10 14:38+0100, Peter Maydell: On 10 July 2015 at 14:31, Radim Krčmář rkrc...@redhat.com wrote: 2015-07-10 13:56+0100, Peter Maydell: On 10 July 2015 at 13:33, Radim Krčmář rkrc...@redhat.com wrote: @@ -83,8 +87,8 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg

[Qemu-devel] [PATCH v2 3/3] crypto: use CPP for wrapper definitions in nettle

It's horrible both ways and I prefer this one. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- crypto/cipher-nettle.c | 47 +-- 1 file changed, 17 insertions(+), 30 deletions(-) diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c index

[Qemu-devel] [PATCH v2 2/3] crypto: avoid undefined behavior in nettle calls

won't be done if we drop argument's true type, and pointers can have different sizes so passing arguments on stack would bug.) Having two different prototypes based on nettle version doesn't make this solution any nicer. Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Radim

Re: [Qemu-devel] [PATCH] crypt: fix build with nettle = 3.0.0

2015-07-10 14:56+0100, Peter Maydell: On 10 July 2015 at 14:38, Peter Maydell peter.mayd...@linaro.org wrote: On 10 July 2015 at 14:31, Radim Krčmář rkrc...@redhat.com wrote: We pass 'ctx' as a 'void *' in the code, but these functions accept specialized structures, which makes them

[Qemu-devel] [PATCH v2 0/3] crypto: nettle fixes

[1/3] fixes a build problem with new nettle libraries. Peter Maydell found a potential undefined behavior with some architectures that is fixed in [2/3]. (I haven't checked if QEMU runs on one.) [3/3] refactors [2/3]; feel free to squish or drop it. Radim Krčmář (3): crypto: fix build

[Qemu-devel] [PATCH v2 1/3] crypto: fix build with nettle = 3.0.0

versions. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- configure | 4 +++- crypto/cipher-nettle.c | 16 ++-- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 33b945530e64..cc0338ddbd14 100755 --- a/configure +++ b/configure

[Qemu-devel] [PATCH build-fix] target-i386: emulate CPUID level of real hardware

http://instlatx64.atw.hu/ as a source of CPUID and checked that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M, and Haswell i5-4670T. kvm64 and qemu64 were bumped to 0xD to allow all available features for them (and to avoid the same Windows bug). Signed-off-by: Radim

Re: [Qemu-devel] [PULL 0/3] X86 queue, 2015-07-03

2015-07-06 10:39-0300, Eduardo Habkost: On Sun, Jul 05, 2015 at 07:33:31PM +0100, Peter Maydell wrote: On 3 July 2015 at 21:47, Eduardo Habkost ehabk...@redhat.com wrote: The following changes since commit 35360642d043c2a5366e8a04a10e5545e7353bd5: Merge remote-tracking branch

Re: [Qemu-devel] [PATCH v2] target-i386: emulate CPUID level of real hardware

2015-06-19 12:52-0300, Eduardo Habkost: On Fri, Jun 19, 2015 at 01:20:40PM +0200, Radim Krčmář wrote: [...] diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c @@ -307,6 +307,24 @@ static void pc_init1(MachineState *machine) static void pc_compat_2_3(MachineState *machine

[Qemu-devel] [PATCH v3] target-i386: emulate CPUID level of real hardware

http://instlatx64.atw.hu/ as a source of CPUID and checked that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M, and Haswell i5-4670T. kvm64 and qemu64 were bumped to 0xD to allow all available features for them (and to avoid the same Windows bug). Signed-off-by: Radim

Re: [Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd

2015-06-19 11:47+0200, Radim Krčmář: 2015-06-18 12:50-0300, Eduardo Habkost: I have considered introducing min-[x]level and max-{x]level properties to control automatic increasing of level/xlevel. The existing X86CPUDefinition.level field could just control min_level, while explicit level

[Qemu-devel] [PATCH v2] target-i386: emulate CPUID level of real hardware

used http://instlatx64.atw.hu/ as a source of CPUID and checked that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M, and Haswell i5-4670T. kvm64 and qemu64 were bumped to 0xD to allow all available features for them (and to avoid the same Windows bug). Signed-off-by: Radim

Re: [Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd

2015-06-18 12:50-0300, Eduardo Habkost: On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Krčmář wrote: We already bump to level 7 if features there are requested, so do the same for 0xD. Signed-off-by: Radim Krčmář rkrc...@redhat.com This breaks guest ABI and live-migration, as CPUID

Re: [Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd

2015-06-19 11:47+0200, Radim Krčmář: 2015-06-18 12:50-0300, Eduardo Habkost: I have considered introducing min-[x]level and max-{x]level properties to control automatic increasing of level/xlevel. The existing X86CPUDefinition.level field could just control min_level, while explicit level

Re: [Qemu-devel] [PATCH 1/2] target-i386: emulate CPUID level of real hardware

2015-06-18 17:29+0200, Paolo Bonzini: On 18/06/2015 17:24, Radim Krčmář wrote: W10 insider has a bug where it ignores CPUID level and interprets CPUID.(EAX=07H, ECX=0H) incorrectly, because CPUID in fact returned CPUID.(EAX=04H, ECX=0H); this resulted in execution of unsupported

[Qemu-devel] [PATCH 1/2] target-i386: emulate CPUID level of real hardware

; and amend xlevel while at it. I have used http://instlatx64.atw.hu/ as a source of CPUID and checked that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge i5-2540M, and Haswell i5-4670T. kvm64 and qemu64 were bumped to 0xD to avoid similar problems. Signed-off-by: Radim Krčmář rkrc

[Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd

We already bump to level 7 if features there are requested, so do the same for 0xD. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- If we want this behavior, we should not do it by writing a case for every level. target-i386/cpu.c | 4 1 file changed, 4 insertions(+) diff --git

[Qemu-devel] [PATCH 0/2] target-i386: fix W10 bug and bring CPUID levels closer to reality

The first patch uses CPUID levels from the internet, which has a nice side effect of making W10 insider preview bootable. The second patch is a traditional buggy bug fix. Radim Krčmář (2): target-i386: emulate CPUID level of real hardware target-i386: automatically raise cpuid level to 0xd

Re: [Qemu-devel] [PATCH] pc: acpi: keep pvpanic backward compatible

2015-05-29 10:51+0200, Igor Mammedov: On Wed, 27 May 2015 18:29:17 +0200 Radim Krčmář rkrc...@redhat.com wrote: In the old times, we always had pvpanic in ACPI and a _STA function told the guest not to use it. Now, we only include pvpanic in ACPI if it is enabled, so the _STA function

[Qemu-devel] [PATCH v2] pc: acpi: fix pvpanic for buggy guests

) } Else { Return (0x0F) }} Igor pointed out that we don't need to use a method to return a constant and that 0xB (don't show in UI) is the common definition now. Also, the device used to be PEVT. (PEVT as in panic event?) Signed-off-by: Radim Krčmář rkrc...@redhat.com --- v2: Use

[Qemu-devel] [PATCH] pc: acpi: keep pvpanic backward compatible

' on this result is completely beyond me.) Also, the device used to be PEVT. (PEVT as in panic event?) Signed-off-by: Radim Krčmář rkrc...@redhat.com --- hw/i386/acpi-build.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index

Re: [Qemu-devel] [PATCH v2 RESEND 1/5] apic: Implement LAPIC low priority arbitration functions

2015-04-23 12:34-0600, James Sullivan: On 04/23/2015 07:49 AM, Radim Krčmář wrote: 2015-04-06 17:45-0600, James Sullivan: Currently, apic_get_arb_pri() is unimplemented and returns 0. Implemented apic_get_arb_pri() and added two helper functions apic_compare_prio() and apic_lowest_prio

Re: [Qemu-devel] [PATCH v2 RESEND 5/5] apic: Implement handling of RH=1 for MSI interrupt delivery

2015-04-23 13:08-0600, James Sullivan: On 04/23/2015 08:14 AM, Radim Krčmář wrote: 2015-04-06 17:45-0600, James Sullivan: diff --git a/hw/intc/apic.c b/hw/intc/apic.c @@ -519,23 +521,27 @@ static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, +if (apic_match_dest

Re: [Qemu-devel] [PATCH v2 RESEND 5/5] apic: Implement handling of RH=1 for MSI interrupt delivery

2015-04-06 17:45-0600, James Sullivan: Added argument to apic_get_delivery_bitmask() for msi_redir_hint, and changed calls to the function accordingly (using 0 as a default value for non-MSI interrupts). Modified the implementation of apic_get_delivery_bitmask() to account for the RH bit of

Re: [Qemu-devel] [PATCH v2 RESEND 1/5] apic: Implement LAPIC low priority arbitration functions

2015-04-06 17:45-0600, James Sullivan: Currently, apic_get_arb_pri() is unimplemented and returns 0. Implemented apic_get_arb_pri() and added two helper functions apic_compare_prio() and apic_lowest_prio() to be used for LAPIC arbitration. Signed-off-by: James Sullivan

Re: [Qemu-devel] E5-2620v2 - emulation stop error

2015-03-31 21:23+0300, Andrey Korolyov: On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das b...@redhat.com wrote: Bandan Das b...@redhat.com writes: Andrey Korolyov and...@xdel.ru writes: ... http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz Something a bit

Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang

2015-03-31 13:26+0800, Jason Wang: On 02/20/2015 03:24 AM, Radim Krčmář wrote: Window 8.0 driver has a particular behavior for a small time frame after it enables rx interrupts: the interrupt handler never clears E1000_ICR_RXT0. The handler does this something like this: set_imc(-1

<    1   2   3   >