diff mbox

xen: avoid tracking the region 0xa0000 - 0xbffff

Message ID 1307116614-11775-1-git-send-email-stefano.stabellini@eu.citrix.com
State New
Headers show

Commit Message

Stefano Stabellini June 3, 2011, 3:56 p.m. UTC
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(-)

Comments

Jan Kiszka June 14, 2011, 11:04 a.m. UTC | #1
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
Stefano Stabellini June 14, 2011, 11:48 a.m. UTC | #2
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.
Stefano Stabellini June 14, 2011, 11:50 a.m. UTC | #3
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...
Alexander Graf June 14, 2011, 11:52 a.m. UTC | #4
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
Jan Kiszka June 14, 2011, 11:59 a.m. UTC | #5
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
Avi Kivity June 14, 2011, 4:47 p.m. UTC | #6
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.
diff mbox

Patch

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;
     }