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: "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 14:43:06 -0000
Delivery-date: Sat, 27 Jan 2007 06:43:18 -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: <C1E0DCB5.7E78%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhNpSgnLlsyleeR3aZurd/xO5mYAAmjw1QAHpYsZANUy+bAAbmp7kgAzBSt0AAA6R4dgADlbrAAByKhhoAAgYC0AABZeHTAAhnpzA=
Thread-topic: [Xen-devel] Re: [Patch] the interface of invalidating qemumapcache
> > Keir,
> > Attached is the updated version. The exported
qemu_invalidate_map_cache()
> just
> > blows the entire qemu mapcache.
> > Would you please give some comments? Thanks a lot!
> 
> 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.

Ian 


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