All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: Fix page-crossing MMIO
Date: Thu, 19 Apr 2012 12:07:29 +0300	[thread overview]
Message-ID: <4F8FD5D1.1070403@redhat.com> (raw)
In-Reply-To: <20120419085915.GX11918@redhat.com>

On 04/19/2012 11:59 AM, Gleb Natapov wrote:
> On Wed, Apr 18, 2012 at 07:22:47PM +0300, Avi Kivity wrote:
> > MMIO that are split across a page boundary are currently broken - the
> > code does not expect to be aborted by the exit to userspace for the
> > first MMIO fragment.
> > 
> > This patch fixes the problem by generalizing the current code for handling
> > 16-byte MMIOs to handle a number of "fragments", and changes the MMIO
> > code to create those fragments.
> > 
> For 16 bit IO userspace will see two 8bit writes. Is this OK? 

I believe so.  The Pentium bus was 64-bit wide with no address lines
A0-A2, instead it had byte enables BE0-BE7.  So a write that crosses a
quadword boundary would be split.  Similarly the 32-bit PCI bus has 4
byte enables, so anything that crosses a dword boundary is split. 
LOCKed ops are implemented by asserting a signal during the two
operations.  No idea how it's implemented with modern busless
processors, but the same semantics have been kept, probably.

Even more interesting is that a 32-bit write is seen as an 8 bit write
followed by a 24-bit write.

Note also that the two accesses can target different devices.

> Is there
> real code that does this kind of IO, or the patch is for correctness
> only?

I should have mentioned it in the changelog - it's Windows 95.  There is
also a Red Hat Linux version that does something like this, I remember
adding some code in qemu-kvm to handle the 3-byte write.  So I guess
this fixes a regression.

(not sure - in the Windows 95 case we have a write to VGA that crosses a
page boundary (but the pages are physically contiguous, nothing strange
is going on; the RHL case was writing partially to RAM and partially to
unallocated memory, so it might work with the current code).

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2012-04-19  9:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 16:22 [PATCH] KVM: Fix page-crossing MMIO Avi Kivity
2012-04-19  8:59 ` Gleb Natapov
2012-04-19  9:07   ` Avi Kivity [this message]
2012-04-19 23:35 ` Marcelo Tosatti

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=4F8FD5D1.1070403@redhat.com \
    --to=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /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.