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

Re: [Xen-devel] Re: [Patch] the interface of invalidating qemu mapcache


  • To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sat, 27 Jan 2007 10:40:53 +0000
  • Delivery-date: Sat, 27 Jan 2007 02:40:41 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbhNpSgnLlsyleeR3aZurd/xO5mYAAmjw1QAHpYsZANUy+bAAbmp7kgAzBSt0AAA6R4dgADlbrAAByKhhoAAgYC0AABZeHT
  • Thread-topic: [Xen-devel] Re: [Patch] the interface of invalidating qemu mapcache

On 27/1/07 10:29 am, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:

> 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.

 -- Keir



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


 


Rackspace

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