WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [Patch] the interface of invalidating qemumapcache

To: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [Patch] the interface of invalidating qemumapcache
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 27 Jan 2007 16:35:34 -0000
Delivery-date: Sat, 27 Jan 2007 08:35:53 -0800
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>
References: <8FFF7E42E93CC646B632AB40643802A801E8C33C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhNpSgnLlsyleeR3aZurd/xO5mYAAmjw1QAHpYsZANUy+bAAbmp7kgAzBSt0AAA6R4dgADlbrAAByKhhoAAgYC0AABZeHTAAhnpzAAAPIroAADAPfw
Thread-topic: [Xen-devel] Re: [Patch] the interface of invalidating qemumapcache
> >> Allocating the PCI resources with an incrementing region_num
counter
> >> is pointless (and in fact confusing) given that the BAR for mmio
and
> >> portio resources are hardcoded as 1 and 0 (respectively) in the
> >> pv-on-hvm driver code. Also the existing portio resource is (I
> >> believe) a placeholder. Thus you don't need to create a new
resource
> >> -- use the first port of resource region 0 instead. The existing
> >> read/write handler registrations in platform_io_map() are
pointless.
> >> You can remove them and replace with a single-byte write handler to
> >> blow the mapcache -- there's no need to install handlers for 2- or
> >> 4-byte accesses, nor for read accesses.
> >
> > Why are we triggering this with an ioport access rather than just
> > adding a new message type between xen and qemu-dm? The latter seems
> > rather cleaner.
> 
> Since qemu-dm is reponsible for I/O events, I think it's natural (i.e.
> kind of chipset featrue) to construct and send an I/O event to qemu-dm
> to trigger mapcache invalidation. It does not mean the guest needs to
> use an I/O instruction, but our plan is that Xen sends a mapcache
> invalidation message and it's implemented as an I/O event for HVM
> guests.

Ah, OK -- so this is just for testing purposes. Seems sensible.
Thanks,
Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel