From: "Michael S. Tsirkin" <mst@redhat.com>
To: Bernhard Kohl <bernhard.kohl@nsn.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH RESENT] msix: allow byte and word reading from mmio
Date: Mon, 15 Nov 2010 12:42:00 +0200 [thread overview]
Message-ID: <20101115104200.GI22248@redhat.com> (raw)
In-Reply-To: <1282222611-21192-1-git-send-email-bernhard.kohl@nsn.com>
On Thu, Aug 19, 2010 at 02:56:51PM +0200, Bernhard Kohl wrote:
> It's legal that the guest reads a single byte or word from mmio.
Interesting. The spec seems to say this:
For all accesses to MSI-X Table and MSI-X PBA fields, software must use
aligned full DWORD or aligned full QWORD transactions; otherwise, the
result is undefined.
> I have an OS which reads single bytes and it works fine on real
> hardware. Maybe this happens due to casting.
What do you mean by casting?
>
> Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com>
I guess we can merge this, but we need a comment I think since this
seems to contradict the spec, and people were sending patches relying on
this.
Does something like the following describe the situation correctly?
/* Note: PCI spec requires that all MSI-X table accesses
are either DWORD or QWORD, size aligned. Some guests seem to violate
this rule for read accesses, performing single byte reads.
Since it's easy to support this, let's do so.
Also support 16 bit size aligned reads, just in case.
*/
Does you guest also do 16 bit reads? Are accesses at least aligned?
> ---
> hw/msix.c | 20 ++++++++++++++++----
> 1 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/hw/msix.c b/hw/msix.c
> index d99403a..7dac7f7 100644
> --- a/hw/msix.c
> +++ b/hw/msix.c
> @@ -100,10 +100,22 @@ static uint32_t msix_mmio_readl(void *opaque, target_phys_addr_t addr)
> return pci_get_long(page + offset);
> }
>
> -static uint32_t msix_mmio_read_unallowed(void *opaque, target_phys_addr_t addr)
> +static uint32_t msix_mmio_readw(void *opaque, target_phys_addr_t addr)
> {
> - fprintf(stderr, "MSI-X: only dword read is allowed!\n");
> - return 0;
> + PCIDevice *dev = opaque;
> + unsigned int offset = addr & (MSIX_PAGE_SIZE - 1) & ~0x1;
> + void *page = dev->msix_table_page;
> +
> + return pci_get_word(page + offset);
> +}
> +
> +static uint32_t msix_mmio_readb(void *opaque, target_phys_addr_t addr)
> +{
> + PCIDevice *dev = opaque;
> + unsigned int offset = addr & (MSIX_PAGE_SIZE - 1);
> + void *page = dev->msix_table_page;
> +
> + return pci_get_byte(page + offset);
> }
>
> static uint8_t msix_pending_mask(int vector)
> @@ -198,7 +210,7 @@ static CPUWriteMemoryFunc * const msix_mmio_write[] = {
> };
>
> static CPUReadMemoryFunc * const msix_mmio_read[] = {
> - msix_mmio_read_unallowed, msix_mmio_read_unallowed, msix_mmio_readl
> + msix_mmio_readb, msix_mmio_readw, msix_mmio_readl
> };
>
> /* Should be called from device's map method. */
> --
> 1.7.2.1
next prev parent reply other threads:[~2010-11-15 10:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 12:56 [Qemu-devel] [PATCH RESENT] msix: allow byte and word reading from mmio Bernhard Kohl
2010-08-22 21:34 ` Anthony Liguori
2010-11-15 9:43 ` Bernhard Kohl
2010-11-15 10:42 ` Michael S. Tsirkin [this message]
2010-11-15 16:40 ` [Qemu-devel] " Bernhard Kohl
2010-11-15 19:51 ` Michael S. Tsirkin
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=20101115104200.GI22248@redhat.com \
--to=mst@redhat.com \
--cc=bernhard.kohl@nsn.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).