qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Radim Krčmář
Subject: Re: [Qemu-devel] [RFC 0/4] APIC, IOMMU, KVM: add x2APIC interface
Date: Mon, 9 May 2016 16:35:24 +0200

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 kernel interface could use your comments, but internal QEMU one is
>> in dire need of them.  Please see [1/4].
>> 
>> I have tested the series and seems to work as well as it can.
>> Peter's IR v6 didn't boot on my setup, so I reverted to the latest
>> version I know was working, v4, and rebased paches for testing.
> 
> Radim,
> 
> Would you please provide your test setup? So that I can try to
> reproduce it on my machine and debug it. 

I could reproduce with a kernel based off kvm/queue (basically 4.6-rc3),
that was make olconfig with fedora rawhide config for 4.6-rc3 and
qemu/master (53db932604d) after pulling your vtd-intr-v6 and doing the
minimum to make ./configure happy.

The bug was caused by pci-bridge, which I didn't remove from a
copy-pasted qemu line ... Linux boot hangs if QEMU is ran with
 -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \
 -drive file=/home/rhel7.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \
 -device 
virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 \

but the following works
 -drive file=/home/rhel7.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \
 -device 
virtio-blk-pci,scsi=off,bus=pcie.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 \

I can give you ssh access to the machine too.

>> The setup from Igor's latest x2APIC QEMU patches creates two VCPUs,
>> first has id 0 and second has 280.  Edge IO-APIC and MSI interrupts
>> were being delivered to both of them, but level didn't work -- only
>> one interrupt was ever delivered, I blame EOI.
> 
> Not sure whether this is related to the v5 fix on kernel EOI hack
> (the two patches that you have reviewed)? That two patches should
> solve the level-triggered interrupt issue that I have encountered,
> like e1000 cards.

I didn't try the R/O preserving patch, but the other one on top of v4
changed nothing.  (There might be some kernel bugs too, because I
expected that EOI would start working with it ...)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]