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/
Home Products Support Community News


RE: [Xen-devel][PATCH]Fix the read error from IRR,ISR and TMR

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel][PATCH]Fix the read error from IRR,ISR and TMR
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 1 Sep 2006 15:44:22 +0800
Delivery-date: Fri, 01 Sep 2006 00:45:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AcbM0cC4LzpDP1xsScihn3p0rzSgGAAeuNQ6ABGNJxA=
Thread-topic: [Xen-devel][PATCH]Fix the read error from IRR,ISR and TMR
Keir Fraser wrote:
> Since it turns out that *all* registers are 128-bit aligned and
> 32-bits, I think the regs block should be changed to be an array of
> 32-bit registers, skipping the unused parts of the APIC page (i.e.,
> so that register x can be found by regs[x>>4]). Then the bitmaps
> would be conveniently contiguous again! And since the array would be
> only 1kB, it would mean we can get rid of the alloc_domheap_page()
> and map_domain_page_global(). 
        Yes, skipping the unused parts and compact them together will
benefit us now :-) While then we may not be able to do CR8 acceleration.
The later one will need an APIC page to back for guest APIC states,
currently it is only TPR (CR8) base on VT spec. So 4K memory per
processor for each APIC page is unavoidable. 
        Meanwhile, we are thinking about another important enhancement
to accelerate some proprietary OS which will frequently access TPR. In
that patch, the APIC page is directly mapped to guest as "RO" that
greatly increase UP OS performance in our test. But the patch today is
still hold on due to SMP support issue, as today's shadow page table is
still global. I believe eventually shadow page table will be per VP, and
the APIC acceleration patch will be out too. Then eventually we need to
organize the APIC data in hardware format like Xiaohui's patch show.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>