From: Peter Xu <peterx@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <rth@twiddle.net>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 3/8] intel_iommu: pass whole remapped addresses to apic
Date: Sat, 8 Oct 2016 13:24:55 +0800 [thread overview]
Message-ID: <20161008052455.GB3666@pxdev.xzpeter.org> (raw)
In-Reply-To: <20161004131728.76623dbe@nial.brq.redhat.com>
On Tue, Oct 04, 2016 at 01:17:28PM +0200, Igor Mammedov wrote:
> On Fri, 30 Sep 2016 18:10:08 +0200
> Radim Krčmář <rkrcmar@redhat.com> wrote:
>
> > 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.
> >
> > Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
> > ---
> > v2: fix build with enabled DEBUG_INTEL_IOMMU [Peter]
> > ---
> > hw/i386/intel_iommu.c | 21 +++++++++------------
> > 1 file changed, 9 insertions(+), 12 deletions(-)
> >
> > 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"
> >
> > /*#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_addr_reg,
> > hwaddr mesg_data_reg)
> > {
> > - hwaddr addr;
> > - uint32_t data;
> > + MSIMessage msi;
> >
> > assert(mesg_data_reg < DMAR_REG_SIZE);
> > assert(mesg_addr_reg < DMAR_REG_SIZE);
> >
> > - addr = vtd_get_long_raw(s, mesg_addr_reg);
> > - data = vtd_get_long_raw(s, mesg_data_reg);
> > + msi.address = vtd_get_long_raw(s, mesg_addr_reg);
> > + msi.data = vtd_get_long_raw(s, mesg_data_reg);
> >
> > - 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);
> > }
> >
> > /* Generate a fault event to software via MSI if conditions are met.
> > @@ -2133,6 +2133,7 @@ static void vtd_generate_msi_message(VTDIrq *irq, MSIMessage *msg_out)
> > msg.dest_mode = irq->dest_mode;
> > msg.redir_hint = irq->redir_hint;
> > msg.dest = irq->dest;
> > + msg.__addr_hi = irq->dest & 0xffffff00;
> what about BE host? should it be:
>
> msg.__addr_hi = cpu_to_le32(irq->dest & 0xffffff00)
>
> Also question to Peter, why __addr_hi is not HOST_WORDS_BIGENDIAN conditioned?
> now we have:
> struct VTD_MSIMessage {
> union {
> struct {
> #ifdef HOST_WORDS_BIGENDIAN
> uint32_t __addr_head:12; /* 0xfee */
> [...]
> #else
> [...]
> uint32_t __addr_head:12; /* 0xfee */
> #endif
> uint32_t __addr_hi:32;
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
next prev parent reply other threads:[~2016-10-08 5:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-30 16:10 [Qemu-devel] [PATCH v3 0/8] intel_iommu: fix EIM Radim Krčmář
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 1/8] apic: add global apic_get_class() Radim Krčmář
2016-10-03 16:03 ` Eduardo Habkost
2016-10-04 10:59 ` Igor Mammedov
2016-10-04 13:38 ` Radim Krčmář
2016-10-04 16:14 ` Eduardo Habkost
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 2/8] apic: add send_msi() to APICCommonClass Radim Krčmář
2016-10-04 11:06 ` Igor Mammedov
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 3/8] intel_iommu: pass whole remapped addresses to apic Radim Krčmář
2016-10-04 11:17 ` Igor Mammedov
2016-10-08 5:24 ` Peter Xu [this message]
2016-10-09 20:47 ` Michael S. Tsirkin
2016-10-09 22:46 ` Peter Xu
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 4/8] intel_iommu: redo configuraton check in realize Radim Krčmář
2016-10-04 11:40 ` Igor Mammedov
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 5/8] intel_iommu: add OnOffAuto intr_eim as "eim" property Radim Krčmář
2016-10-04 12:34 ` Igor Mammedov
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 6/8] intel_iommu: reject broken EIM Radim Krčmář
2016-10-04 13:43 ` Igor Mammedov
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type Radim Krčmář
2016-10-04 12:18 ` Igor Mammedov
2016-10-04 13:48 ` Radim Krčmář
2016-09-30 16:10 ` [Qemu-devel] [PATCH v3 8/8] target-i386/kvm: cache the return value of kvm_enable_x2apic() Radim Krčmář
2016-10-04 11:33 ` Igor Mammedov
2016-10-04 13:45 ` Radim Krčmář
2016-09-30 17:22 ` [Qemu-devel] [PATCH v3 0/8] intel_iommu: fix EIM no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161008052455.GB3666@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.