From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsk8A-0002b5-BT for qemu-devel@nongnu.org; Sat, 08 Oct 2016 01:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsk85-0007VZ-D0 for qemu-devel@nongnu.org; Sat, 08 Oct 2016 01:25:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsk85-0007Uv-3Z for qemu-devel@nongnu.org; Sat, 08 Oct 2016 01:25:01 -0400 Date: Sat, 8 Oct 2016 13:24:55 +0800 From: Peter Xu Message-ID: <20161008052455.GB3666@pxdev.xzpeter.org> References: <20160930161013.9832-1-rkrcmar@redhat.com> <20160930161013.9832-4-rkrcmar@redhat.com> <20161004131728.76623dbe@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161004131728.76623dbe@nial.brq.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 3/8] intel_iommu: pass whole remapped addresses to apic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= , qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" On Tue, Oct 04, 2016 at 01:17:28PM +0200, Igor Mammedov wrote: > On Fri, 30 Sep 2016 18:10:08 +0200 > Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >=20 > > The MMIO interface to APIC only allowed 8 bit addresses, which is not > > enough for 32 bit addresses from EIM remapping. > > Intel stored upper 24 bits in the high MSI address, so use the same > > technique. The technique is also used in KVM MSI interface. > > Other APICs are unlikely to handle those upper bits. > >=20 > > Signed-off-by: Radim Kr=C4=8Dm=C3=A1=C5=99 > > --- > > v2: fix build with enabled DEBUG_INTEL_IOMMU [Peter] > > --- > > hw/i386/intel_iommu.c | 21 +++++++++------------ > > 1 file changed, 9 insertions(+), 12 deletions(-) > >=20 > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > > index 9f4e64af1ad5..c39b62b898d8 100644 > > --- a/hw/i386/intel_iommu.c > > +++ b/hw/i386/intel_iommu.c > > @@ -31,6 +31,7 @@ > > #include "hw/i386/x86-iommu.h" > > #include "hw/pci-host/q35.h" > > #include "sysemu/kvm.h" > > +#include "hw/i386/apic_internal.h" > > =20 > > /*#define DEBUG_INTEL_IOMMU*/ > > #ifdef DEBUG_INTEL_IOMMU > > @@ -279,18 +280,17 @@ static void vtd_update_iotlb(IntelIOMMUState *s= , uint16_t source_id, > > static void vtd_generate_interrupt(IntelIOMMUState *s, hwaddr mesg_a= ddr_reg, > > hwaddr mesg_data_reg) > > { > > - hwaddr addr; > > - uint32_t data; > > + MSIMessage msi; > > =20 > > assert(mesg_data_reg < DMAR_REG_SIZE); > > assert(mesg_addr_reg < DMAR_REG_SIZE); > > =20 > > - addr =3D vtd_get_long_raw(s, mesg_addr_reg); > > - data =3D vtd_get_long_raw(s, mesg_data_reg); > > + msi.address =3D vtd_get_long_raw(s, mesg_addr_reg); > > + msi.data =3D vtd_get_long_raw(s, mesg_data_reg); > > =20 > > - VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32, addr,= data); > > - address_space_stl_le(&address_space_memory, addr, data, > > - MEMTXATTRS_UNSPECIFIED, NULL); > > + VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32, > > + msi.address, msi.data); > > + apic_get_class()->send_msi(&msi); > > } > > =20 > > /* Generate a fault event to software via MSI if conditions are met. > > @@ -2133,6 +2133,7 @@ static void vtd_generate_msi_message(VTDIrq *ir= q, MSIMessage *msg_out) > > msg.dest_mode =3D irq->dest_mode; > > msg.redir_hint =3D irq->redir_hint; > > msg.dest =3D irq->dest; > > + msg.__addr_hi =3D irq->dest & 0xffffff00; > what about BE host? should it be: >=20 > msg.__addr_hi =3D cpu_to_le32(irq->dest & 0xffffff00) >=20 > Also question to Peter, why __addr_hi is not HOST_WORDS_BIGENDIAN condi= tioned? > now we have: > struct VTD_MSIMessage { = =20 > union { = =20 > struct { = =20 > #ifdef HOST_WORDS_BIGENDIAN = =20 > uint32_t __addr_head:12; /* 0xfee */ = =20 > [...] =20 > #else = =20 > [...] > uint32_t __addr_head:12; /* 0xfee */ = =20 > #endif = =20 > uint32_t __addr_hi:32;=20 I think __addr_hi is not a bit field at all. It'll be the same if I put it into the block. E.g., it'll look like: #ifdef HOST_WORDS_BIGENDIAN uint32_t __addr_head:12; /* 0xfee */ uint32_t dest:8; uint32_t __reserved:8; uint32_t redir_hint:1; uint32_t dest_mode:1; uint32_t __not_used:2; uint32_t __addr_hi:32; #else uint32_t __not_used:2; uint32_t dest_mode:1; uint32_t redir_hint:1; uint32_t __reserved:8; uint32_t dest:8; uint32_t __addr_head:12; /* 0xfee */ uint32_t __addr_hi:32; #endif Only real bit fields (like dest_mode, redir_hint, etc.) order is handled differently on BE/LE machines. Since __addr_hi is not a bit field (it's typed as u32, and it's 32 bits long), it should always be using a higher address comparing to above real bit fields, so no ordering issue AFAIK. I have patch in my queue that fixes this (change "__addr_hi:32" to "__addr_hi"). Though it should not be a big problem. -- peterx