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] [PATCH]RFC: VGA accleration using shadow PTE D-bit to co

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap
From: "Huang, Xinmei" <xinmei.huang@xxxxxxxxx>
Date: Mon, 30 Jul 2007 18:41:14 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Mon, 30 Jul 2007 03:39:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070730085807.GB24708@xxxxxxxxxxxxxxxxxxxxx>
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: AcfSh8cMIFEZg5bQTxK9XmiAJ+RMPQAAS0bA
Thread-topic: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap
Tim, thanks for your comments, pls see the embedded.

>-----Original Message-----
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx] 
>Sent: 2007年7月30日 16:58
>To: Huang, Xinmei
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian.Pratt@xxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH]RFC: VGA accleration using 
>shadow PTE D-bit to construct LFB dirty bitmap
>
>Hi,
>
>At 16:10 +0800 on 28 Jul (1185639053), Huang, Xinmei wrote:
>> With current accelerated VGA for qemu-dm, guest can access 
>LFB directly,
>> however, qemu-dm is not conscious of these accesses to LFB. The
>> accompanying task is to determine the range of LFB to be redrawn on
>> guest display window. Current qemu-dm maintains a copy of 
>LFB, and gets
>> the LFB dirty-bitmap through memcmp. This patch adopts another way to
>> get the LFB dirty-bitmap: one hypercall to instruct 
>hypervisor to fill
>> the dirty-bitmap. Hypervisor checks the D-bit of PTEs and updates the
>> dirty-bitmap.
>
>Thanks for this -- those numbers look very good!
>
>The shadow-code modifications seem to have a lot of moving parts,
>though.  Since we expect that the guest will have a single, contiguous,
>kernel-mode mapping of the LFB, we should be able to do this with less
>administration:
>
> - Figure out the VA of the writable mapping of the LFB.
> - When asked for the bitmap, walk the shadow linear page tables of the

When current != vcpu-of-guest, can we use this mechanism or map_shadow_page() 
to access shadow pages?

>   area, recording and clearing the _PAGE_DIRTY bits.  If you see a PTE
>   pointing at the wrong place, back off and tell qemu to try the slow
>   way.  If you see an LFB mfn with a writeable count > 1, either give
>   up or assume it's dirty.  (If you take a page-fault, then the guest
>   has marked his writeable mapping of the LFB non-writable at a higher
>   level -- probably just back off at that point).
> - When a shadow PTE pointing at the LFB is made or cleared, 
>set the bit
>   in the bitmap.
>
>That involves a single equality test in sh_page_fault() to spot the VA,

Guest's va mapped to LFB is assumed to be invariable? 

>a few lines in shadow_set_l1e() to spot new/departing mappings, and
>almost everything else can happen in one routine that reads/writes the
>linear pagetables with a single for() loop.
>
>A few other points:
> - The assumption that the LFB is MFN-contiguous is not valid.  You do
>   work around the degug=y allocator's habit of handing out pages
>   backwards, but that's there to alert you to the more general
>   problem of discontiguous mfns.
> - Since the dirty bits are only one per word, they can be atomically
>   cleared without needing locked operations to protect their
>   neighbours. That means that you don't need to pause the domain: the
>   shadow lock will be enough to keep the operation safe.
> - After clearing the dirty bits, you need to flush TLBs to make sure
>   they'll get set again.  VMX guests get their TLBs flushed on every
>   VMEXIT at the moment, but that's not true on SVM on some hardware,
>   and won't be true on VMX when Intel processors get tagged TLBs.
>

Any more comments on this patch?  Does the Pinned-LFB-shadow idea make sense?


>Cheers,
>
>Tim.
>
>-- 
>Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
>Registered office c/o EC2Y 5EB, UK; company number 05334508
>

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