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

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

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

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.

Jun
---
Intel Open Source Technology Center

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