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
|
Home
xen.org, 