thr3ads.net - Xen devel - [Xen-devel] [PATCH] xen: avoid tracking the region 0xa0000

If this information is useful, please help other people find it:
Share via:

<stefano.stabellini@eu.citrix.com>

2011-Jun-03 15:56 UTC

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

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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@eu.citrix.com>
---
 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) {
+        return -1;
+    }
     if (size <= 0) {
         return -1;
     }
-- 
1.7.2.3


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

<stefano.stabellini@eu.citrix.com>

2011-Jun-03 15:56 UTC

head link

[Xen-devel] [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

If the cirrus_vga PCI BAR is unmapped than we should not only reset
map_addr but also lfb_addr, otherwise we''ll keep trying to map
the old lfb_addr in map_linear_vram.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 722cac7..3c5043e 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3088,8 +3088,11 @@ static void pci_cirrus_write_config(PCIDevice *d,
     CirrusVGAState *s = &pvs->cirrus_vga;
 
     pci_default_write_config(d, address, val, len);
-    if (s->vga.map_addr && d->io_regions[0].addr ==
PCI_BAR_UNMAPPED)
+    if (s->vga.map_addr && d->io_regions[0].addr ==
PCI_BAR_UNMAPPED) {
         s->vga.map_addr = 0;
+        s->vga.lfb_addr = 0;
+        s->vga.lfb_end = 0;
+    }
     cirrus_update_memory_access(s);
 }
 
-- 
1.7.2.3


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

Alexander Graf

2011-Jun-14 10:54 UTC

head link

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

On 03.06.2011, at 17:56, <stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> 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@eu.citrix.com>
> ---
> 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?


Alex


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

Jan Kiszka

2011-Jun-14 11:04 UTC

head link

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

On 2011-06-14 12:54, Alexander Graf wrote:> 
> On 03.06.2011, at 17:56, <stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
> 
>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> 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@eu.citrix.com>
>> ---
>> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano Stabellini

2011-Jun-14 11:48 UTC

head link

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

On Tue, 14 Jun 2011, Alexander Graf wrote:> On 03.06.2011, at 17:56, <stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
> 
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > 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@eu.citrix.com>
> > ---
> > 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.
That is what we were doing before: succeeding the first time and
failing from the second time on.
By "coincidence" the second time was the range 0xa0000-0xbffff so
everything worked as expected, but it wasn''t obvious why.
I am just trying to make sure that one year from now it will be clear
just looking at the code why it works.

> If you don''t want to map the VGA region as memory slot, why not
change the actual mapping code in the cirrus adapter?
Because I didn''t want to introduce any ugly if (xen_enable()) in
generic
code, if it is that simple to catch the issue from xen specific code.

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

Stefano Stabellini

2011-Jun-14 11:50 UTC

head link

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

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@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
> > 
> >> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >> 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@eu.citrix.com>
> >> ---
> >> 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

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

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

Alexander Graf

2011-Jun-14 11:52 UTC

head link

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

On 14.06.2011, at 13:48, Stefano Stabellini wrote:
> On Tue, 14 Jun 2011, Alexander Graf wrote:
>> On 03.06.2011, at 17:56, <stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
>> 
>>> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> 
>>> 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@eu.citrix.com>
>>> ---
>>> 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.
> 
> That is what we were doing before: succeeding the first time and
> failing from the second time on.
> By "coincidence" the second time was the range 0xa0000-0xbffff so
> everything worked as expected, but it wasn''t obvious why.
> I am just trying to make sure that one year from now it will be clear
> just looking at the code why it works.
> 
> 
>> If you don''t want to map the VGA region as memory slot, why
not change the actual mapping code in the cirrus adapter?
> 
> Because I didn''t want to introduce any ugly if (xen_enable()) in
generic
> code, if it is that simple to catch the issue from xen specific code.
Well sure, but 2 years from now yet another region will be introduced that might
even be registered before the FB and everyone''s puzzled again :). How
about you print a warning when anyone tries to map anything after the first map?
Or - as Jan suggests - implement multiple regions.

If you prefer, you could even check for the VGA range as "known
broken" and only print warnings on others.


Alex


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

Jan Kiszka

2011-Jun-14 11:59 UTC

head link

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

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@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
>>>
>>>> From: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>>>>
>>>> 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@eu.citrix.com>
>>>> ---
>>>> 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.

Jan

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

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

Alexander Graf

2011-Jun-14 13:54 UTC

head link

[Xen-devel] Re: [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

On 06/03/2011 05:56 PM, stefano.stabellini@eu.citrix.com
wrote:> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>
> If the cirrus_vga PCI BAR is unmapped than we should not only reset
> map_addr but also lfb_addr, otherwise we''ll keep trying to map
> the old lfb_addr in map_linear_vram.
The patch looks good to me, but I''d love to get an ack from someone who
knows the cirrus code before committing it.


Alex
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   hw/cirrus_vga.c |    5 ++++-
>   1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index 722cac7..3c5043e 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -3088,8 +3088,11 @@ static void pci_cirrus_write_config(PCIDevice *d,
>       CirrusVGAState *s =&pvs->cirrus_vga;
>
>       pci_default_write_config(d, address, val, len);
> -    if (s->vga.map_addr&&  d->io_regions[0].addr ==
PCI_BAR_UNMAPPED)
> +    if (s->vga.map_addr&&  d->io_regions[0].addr ==
PCI_BAR_UNMAPPED) {
>           s->vga.map_addr = 0;
> +        s->vga.lfb_addr = 0;
> +        s->vga.lfb_end = 0;
> +    }
>       cirrus_update_memory_access(s);
>   }
>

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

Alexander Graf

2011-Jun-14 15:24 UTC

head link

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

On 06/14/2011 05:24 PM, Stefano Stabellini wrote:> On Tue, 14 Jun 2011, Alexander Graf wrote:
>> On 14.06.2011, at 13:48, Stefano Stabellini wrote:
>>
>>> On Tue, 14 Jun 2011, Alexander Graf wrote:
>>>> On 03.06.2011, at
17:56,<stefano.stabellini@eu.citrix.com> 
<stefano.stabellini@eu.citrix.com>  wrote:
>>>>
>>>>> From: Stefano
Stabellini<stefano.stabellini@eu.citrix.com>
>>>>>
>>>>> 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@eu.citrix.com>
>>>>> ---
>>>>> 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.
>>> That is what we were doing before: succeeding the first time and
>>> failing from the second time on.
>>> By "coincidence" the second time was the range
0xa0000-0xbffff so
>>> everything worked as expected, but it wasn''t obvious why.
>>> I am just trying to make sure that one year from now it will be
clear
>>> just looking at the code why it works.
>>>
>>>
>>>> If you don''t want to map the VGA region as memory
slot, why not change the actual mapping code in the cirrus adapter?
>>> Because I didn''t want to introduce any ugly if
(xen_enable()) in generic
>>> code, if it is that simple to catch the issue from xen specific
code.
>> Well sure, but 2 years from now yet another region will be introduced
that might even be registered before the FB and everyone''s puzzled
again :). How about you print a warning when anyone tries to map anything after
the first map? Or - as Jan suggests - implement multiple regions.
>>
>> If you prefer, you could even check for the VGA range as "known
broken" and only print warnings on others.
> I can do that (actually we already do it) but it wouldn''t change
the
> fact that if somebody modifies hw/cirrus_vga.c:map_linear_vram to call
> cpu_register_physical_memory_log for the legacy range first, it would
> break xen, that is the problem I was trying to solve.
>
> In order to make the code more reliable, and also catch the scenario
> where another region is registered before the framebuffer, we could do
> something like this, but it is not very pretty:
I agree, but it''s probably the most pretty one I''ve seen so
far. I''ll
let others comment on it too before taking it in.


Alex
>
>
> diff --git a/xen-all.c b/xen-all.c
> index 9a5c3ec..de1e724 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -214,6 +214,7 @@ static int xen_add_to_physmap(XenIOState *state,
>       unsigned long i = 0;
>       int rc = 0;
>       XenPhysmap *physmap = NULL;
> +    RAMBlock *block;
>
>       if (get_physmapping(state, start_addr, size)) {
>           return 0;
> @@ -221,7 +222,16 @@ static int xen_add_to_physmap(XenIOState *state,
>       if (size<= 0) {
>           return -1;
>       }
> +    /* only add the vga vram to physmap */
> +    QLIST_FOREACH(block,&ram_list.blocks, next) {
> +        if (!strcmp(block->idstr, "vga.vram")&& 
block->offset == phys_offset
> +&&  start_addr>  0xbffff) {
> +            goto go_physmap;
> +        }
> +    }
> +    return -1;
>
> +go_physmap:
>       DPRINTF("mapping vram to %llx - %llx, from %llx\n",
start_addr, start_addr + size, phys_offset);
>       for (i = 0; i<  size>>  TARGET_PAGE_BITS; i++) {
>           unsigned long idx = (phys_offset>>  TARGET_PAGE_BITS) + i;

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

Stefano Stabellini

2011-Jun-14 15:24 UTC

head link

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

On Tue, 14 Jun 2011, Alexander Graf wrote:> On 14.06.2011, at 13:48, Stefano Stabellini wrote:
> 
> > On Tue, 14 Jun 2011, Alexander Graf wrote:
> >> On 03.06.2011, at 17:56, <stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
> >> 
> >>> From: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> >>> 
> >>> 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@eu.citrix.com>
> >>> ---
> >>> 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.
> > 
> > That is what we were doing before: succeeding the first time and
> > failing from the second time on.
> > By "coincidence" the second time was the range
0xa0000-0xbffff so
> > everything worked as expected, but it wasn''t obvious why.
> > I am just trying to make sure that one year from now it will be clear
> > just looking at the code why it works.
> > 
> > 
> >> If you don''t want to map the VGA region as memory slot,
why not change the actual mapping code in the cirrus adapter?
> > 
> > Because I didn''t want to introduce any ugly if (xen_enable())
in generic
> > code, if it is that simple to catch the issue from xen specific code.
> 
> Well sure, but 2 years from now yet another region will be introduced that
might even be registered before the FB and everyone''s puzzled again :).
How about you print a warning when anyone tries to map anything after the first
map? Or - as Jan suggests - implement multiple regions.
> 
> If you prefer, you could even check for the VGA range as "known
broken" and only print warnings on others.
I can do that (actually we already do it) but it wouldn''t change the
fact that if somebody modifies hw/cirrus_vga.c:map_linear_vram to call
cpu_register_physical_memory_log for the legacy range first, it would
break xen, that is the problem I was trying to solve.

In order to make the code more reliable, and also catch the scenario
where another region is registered before the framebuffer, we could do
something like this, but it is not very pretty:



diff --git a/xen-all.c b/xen-all.c
index 9a5c3ec..de1e724 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -214,6 +214,7 @@ static int xen_add_to_physmap(XenIOState *state,
     unsigned long i = 0;
     int rc = 0;
     XenPhysmap *physmap = NULL;
+    RAMBlock *block;
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -221,7 +222,16 @@ static int xen_add_to_physmap(XenIOState *state,
     if (size <= 0) {
         return -1;
     }
+    /* only add the vga vram to physmap */
+    QLIST_FOREACH(block, &ram_list.blocks, next) {
+        if (!strcmp(block->idstr, "vga.vram") &&
block->offset == phys_offset
+                && start_addr > 0xbffff) {
+            goto go_physmap;
+        }
+    }
+    return -1;
 
+go_physmap:
     DPRINTF("mapping vram to %llx - %llx, from %llx\n", start_addr,
start_addr + size, phys_offset);
     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
         unsigned long idx = (phys_offset >> TARGET_PAGE_BITS) + i;

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

Jan Kiszka

2011-Jun-14 16:25 UTC

head link

[Xen-devel] Re: [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

On 2011-06-14 15:54, Alexander Graf wrote:> On 06/03/2011 05:56 PM, stefano.stabellini@eu.citrix.com wrote:
>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>
>> If the cirrus_vga PCI BAR is unmapped than we should not only reset
>> map_addr but also lfb_addr, otherwise we''ll keep trying to map
>> the old lfb_addr in map_linear_vram.
> 
> The patch looks good to me, but I''d love to get an ack from
someone who
> knows the cirrus code before committing it.
> 
I''m not claiming to be the cirrus expert, but I''ve just walked
through
all this vga mapping stuff: patch is correct.

Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Alex
> 
>> Signed-off-by: Stefano
Stabellini<stefano.stabellini@eu.citrix.com>
>> ---
>>   hw/cirrus_vga.c |    5 ++++-
>>   1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>> index 722cac7..3c5043e 100644
>> --- a/hw/cirrus_vga.c
>> +++ b/hw/cirrus_vga.c
>> @@ -3088,8 +3088,11 @@ static void pci_cirrus_write_config(PCIDevice
*d,
>>       CirrusVGAState *s =&pvs->cirrus_vga;
>>
>>       pci_default_write_config(d, address, val, len);
>> -    if (s->vga.map_addr&&  d->io_regions[0].addr ==
PCI_BAR_UNMAPPED)
>> +    if (s->vga.map_addr&&  d->io_regions[0].addr ==
PCI_BAR_UNMAPPED) {
>>           s->vga.map_addr = 0;
>> +        s->vga.lfb_addr = 0;
>> +        s->vga.lfb_end = 0;
>> +    }
>>       cirrus_update_memory_access(s);
>>   }
>>
-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

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

Avi Kivity

2011-Jun-14 16:47 UTC

head link

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

On 06/14/2011 02:04 PM, Jan Kiszka wrote:> 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).
>
Since the memory API eventually passes its decisions to the accelerator 
(tcg/kvm/xen) it shouldn''t be a problem to make the decision there as
to
which region actually gets logged.

-- 
error compiling committee.c: too many arguments to function


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

Alexander Graf

2011-Jun-15 08:09 UTC

head link

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

On 14.06.2011, at 17:24, Stefano Stabellini wrote:
> On Tue, 14 Jun 2011, Alexander Graf wrote:
>> On 14.06.2011, at 13:48, Stefano Stabellini wrote:
>> 
>>> On Tue, 14 Jun 2011, Alexander Graf wrote:
>>>> On 03.06.2011, at 17:56,
<stefano.stabellini@eu.citrix.com>
<stefano.stabellini@eu.citrix.com> wrote:
>>>> 
>>>>> From: Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
>>>>> 
>>>>> 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@eu.citrix.com>
>>>>> ---
>>>>> 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.
>>> 
>>> That is what we were doing before: succeeding the first time and
>>> failing from the second time on.
>>> By "coincidence" the second time was the range
0xa0000-0xbffff so
>>> everything worked as expected, but it wasn''t obvious why.
>>> I am just trying to make sure that one year from now it will be
clear
>>> just looking at the code why it works.
>>> 
>>> 
>>>> If you don''t want to map the VGA region as memory
slot, why not change the actual mapping code in the cirrus adapter?
>>> 
>>> Because I didn''t want to introduce any ugly if
(xen_enable()) in generic
>>> code, if it is that simple to catch the issue from xen specific
code.
>> 
>> Well sure, but 2 years from now yet another region will be introduced
that might even be registered before the FB and everyone''s puzzled
again :). How about you print a warning when anyone tries to map anything after
the first map? Or - as Jan suggests - implement multiple regions.
>> 
>> If you prefer, you could even check for the VGA range as "known
broken" and only print warnings on others.
> 
> I can do that (actually we already do it) but it wouldn''t change
the
> fact that if somebody modifies hw/cirrus_vga.c:map_linear_vram to call
> cpu_register_physical_memory_log for the legacy range first, it would
> break xen, that is the problem I was trying to solve.
> 
> In order to make the code more reliable, and also catch the scenario
> where another region is registered before the framebuffer, we could do
> something like this, but it is not very pretty:
> 
> 
> 
> diff --git a/xen-all.c b/xen-all.c
> index 9a5c3ec..de1e724 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -214,6 +214,7 @@ static int xen_add_to_physmap(XenIOState *state,
>     unsigned long i = 0;
>     int rc = 0;
>     XenPhysmap *physmap = NULL;
> +    RAMBlock *block;
> 
>     if (get_physmapping(state, start_addr, size)) {
>         return 0;
> @@ -221,7 +222,16 @@ static int xen_add_to_physmap(XenIOState *state,
>     if (size <= 0) {
>         return -1;
>     }
> +    /* only add the vga vram to physmap */
Please add a comment here, explaining that Xen can only handle a single dirty
log region for now, and that we want the linear framebuffer to be that region.
Also, please resend with proper patch headers and I''ll pull it into the
xen-next tree.


Alex
> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
> +        if (!strcmp(block->idstr, "vga.vram") &&
block->offset == phys_offset
> +                && start_addr > 0xbffff) {
> +            goto go_physmap;
> +        }
> +    }
> +    return -1;
> 
> +go_physmap:
>     DPRINTF("mapping vram to %llx - %llx, from %llx\n",
start_addr, start_addr + size, phys_offset);
>     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
>         unsigned long idx = (phys_offset >> TARGET_PAGE_BITS) + i;

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

Stefano Stabellini

2011-Jun-15 16:27 UTC

head link

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

On Wed, 15 Jun 2011, Alexander Graf wrote:> Please add a comment here, explaining that Xen can only handle a single
dirty log region for now, and that we want the linear framebuffer to be that
region. Also, please resend with proper patch headers and I''ll pull it
into the xen-next tree.
> 
OK, I''ll do that.

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

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

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

[Xen-devel] [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

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

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

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

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

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

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

[Xen-devel] Re: [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

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

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

[Xen-devel] Re: [PATCH] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped

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

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

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