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
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home