This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re-using the x86_emulate_memop() to perform MMIO for HVM.

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Khoa Huynh" <khoa@xxxxxxxxxx>
Subject: [Xen-devel] Re-using the x86_emulate_memop() to perform MMIO for HVM.
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 3 May 2006 16:50:31 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 03 May 2006 07:50:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZrXi9KsGaNshsmRIeo2rlHZaDQGQChhAeAADY3PZA=
Thread-topic: Re-using the x86_emulate_memop() to perform MMIO for HVM.
As stated earlier, I started looking at a using the x86_emulate_memop()
to support HVM's memory-mapped IO emulation - since that would remove
the need to have two x86 instruction decode paths, and a whole heap of
other semi-duplicated code. Since these are fairly major chunks of code
in each place (not to mention that they are not entirely trivial to
understand in either place), it would be a "Good Thing(tm)" to combine
those bits of code. 

I got as far as I can clear the screen with the BIOS, but I ran into a
bit of a problem: The mmio-request that goes to QEMU needs to be ONE
"atomic" operation, as when we send the request to QEMU, Xen schedules,
and eventually comes back to xxx_resume(), which is not where we need to
be to continue a read-modify-write operation. 

In xen/x86/hvm/platform.c, this is solved by figuring out the entire
operation, and based on that, does a RMW operation to QEMU (such as
IOREQ_TYPE_AND) and we therefore don't have to wait for the read
operation to finish before continuing the write phase. 

As I see it, there's several possibilities to solve this, but none of
them are particularly trivial to implement. 

The easiest one would be to supply a bigger set of function pointers to
x86_mem_emulator, such as and_emulated, or_emulated, xor_emulated, etc.
We could make those optional, and choose the "old" or "new" method based
on the pointer being set to something or not. 

Another possibility would be to split the x86_emulate_memop() up, so
that we can point schedule_tail to the second half of it if necessary -
but I definitely don't like this idea [I am not sure that it would even
work to do this - I haven't actually looked at it]. 

A third, easier, but less pleasing way to solve it would be retain the
current two decode/emulate code-paths, and just add everythign twice
when new scenarios are needed to be decoded - I don't quite like this
idea, but it certainly is the least amount of effort to implement!

Thoughts and comments (aside from the obvious "You should have thought
about this earlier!" ;-) would be welcome... 


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>