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


[Xen-devel] Re: [PATCH] xen: avoid tracking the region 0xa0000 - 0xbffff

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xen: avoid tracking the region 0xa0000 - 0xbffff
From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
Date: Tue, 14 Jun 2011 13:59:32 +0200
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alexander Graf <agraf@xxxxxxx>, "anthony@xxxxxxxxxxxxx" <anthony@xxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Tue, 14 Jun 2011 05:02:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1106141248230.12963@kaball-desktop>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1307116614-11775-1-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <D4463EE3-B9CE-45ED-9371-F2D3E3507898@xxxxxxx> <4DF7403E.6000503@xxxxxxxxxxx> <alpine.DEB.2.00.1106141248230.12963@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/
On 2011-06-14 13:50, Stefano Stabellini wrote:
> On Tue, 14 Jun 2011, Jan Kiszka wrote:
>> On 2011-06-14 12:54, Alexander Graf wrote:
>>> On 03.06.2011, at 17:56, <stefano.stabellini@xxxxxxxxxxxxx> 
>>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>>> From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>>>> Xen can only do dirty bit tracking for one memory region, so we should
>>>> explicitly avoid trying to track the legacy VGA region between 0xa0000
>>>> and 0xbffff, rather than trying and failing.
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>>>> ---
>>>> xen-all.c |    4 ++++
>>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>> diff --git a/xen-all.c b/xen-all.c
>>>> index 9a5c3ec..1fdc2e8 100644
>>>> --- a/xen-all.c
>>>> +++ b/xen-all.c
>>>> @@ -218,6 +218,10 @@ static int xen_add_to_physmap(XenIOState *state,
>>>>     if (get_physmapping(state, start_addr, size)) {
>>>>         return 0;
>>>>     }
>>>> +    /* do not try to map legacy VGA memory */
>>>> +    if (start_addr >= 0xa0000 && start_addr + size <= 0xbffff) {
>>> I don't quite like the hardcoded range here. What exactly is the issue? The 
>>> fact that you can only map a single region? Then do a counter and fail when 
>>> it's > 1. If you don't want to map the VGA region as memory slot, why not 
>>> change the actual mapping code in the cirrus adapter?
>> Err, please no "if (xen_enabled())" in that code. We just got rid of the
>> kvm_enabled() mess. And it doesn't scale, it would be required in e1000
>> as well e.g.
> agreed

[Actually, e1000 is not using dirty logging but coalesced MMIO.]

>> BTW, if Xen is not able to track more than one dirty region, I think
>> it's time to fix that limitation. At some point it may no longer be
>> possible to work around it (who knows how the new memory API will look
>> like in this regard).
> you are right, however it is not a simple fix and at present we don't
> actually need to track more than one region...

Well, you already miss dirty logged VGA/VBE memory access this way
(everything that goes to legacy VGA mem, not the framebuffer BAR). Grub
provides a really poor use experience in that mode.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xen-devel mailing list