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: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "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: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Sat, 27 Jan 2007 07:27:11 -0800
Delivery-date: Sat, 27 Jan 2007 07:26:55 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8A87A9A84C201449A0C56B728ACF491E04F333@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhNpSgnLlsyleeR3aZurd/xO5mYAAmjw1QAHpYsZANUy+bAAbmp7kgAzBSt0AAA6R4dgADlbrAAByKhhoAAgYC0AABZeHTAAhnpzAAAPIroA==
Thread-topic: [Xen-devel] Re: [Patch] the interface of invalidating qemumapcache
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