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

[Jan Kiszka <jan.kiszka@xxxxxxxxxxx>]

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.

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).

Jan

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

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