[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH][HVM] Removing 1:1 mapping from qemu-dm

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
  • Date: Wed, 28 Jun 2006 12:51:00 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 28 Jun 2006 12:51:30 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acaa6panteBPSexpTF6DrtMgf0LpiAAAKZXA
  • Thread-topic: [Xen-devel] [PATCH][HVM] Removing 1:1 mapping from qemu-dm

Keir Fraser wrote:
> On 28 Jun 2006, at 19:02, Nakajima, Jun wrote:
>>> Sorry, I actually meant get/put_page_from_l1e(). Does that make the
>>> problem easier? I'd be prepared to add an extra parameter to those
>>> functions if really necessary.
>> That would be sensible ;-) I think we need to add an extra parameter
>> to those to specify the context (guest or shadow, for example)
>> rather than who's calling.
> Since it's just get/put_page_from_l1e I think we should just duplicate
> the required bits in the shadow code. Could the required parts be
> merged into shadow_get/put_page_from_l1e()? For example, non of the
> I/O-page mapping stuff is needed at all yet. We could for now BUG_ON
> !valid_mfn() and flags in L1_DISALLOW_MASK.

Yes, we can merge the required parts into
We still need to change get/put_page_from_l1e to prevent qemu-dm from
changing type_info, but we don't need to add an extra parameter that

> Could you split your original patch into the updated changes to shadow
> mode, and a separate patch for the actual mapcache logic?

I'll do that. 

Intel Open Source Technology Center

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.