[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Paravirt framebuffer frontend kernel support [1/5]



On Mon, 2006-09-04 at 10:00 +0100, Steven Smith wrote:
> There are still a couple of things from the last round which are
> unfixed.  This is mostly my fault for going on holiday at an
> inconvenient time; sorry about that.

We won't begrudge you a holiday -- hope it was a good one :-)  Leaving
some of the stuff for Markus to reply to

> The big problem with this is that you don't support shadow translate
> mode guests, because the frontend exposes mfns directly to the
> backend.  The correct way of fixing this is to use grant tables, but,
> as Anthony pointed out, that's quite hard due to the amount of memory
> you need to grant access to.
> 
> The easy way of doing this would be to just increase the size of the
> grant tables.  Alternatively, you could add support for granting
> access to ranges of memory, but that sounds like a whole lot of work.
> 
> You could also put in a quick hack of just translating the mfns in the
> backend if the frontend is in shadow translate mode, but that's not
> really very nice.

I wouldn't complain if we go the route Keir suggested and have Xen do
it ;-)  But if not, I think that given the size of the memory in
question + grant tables, the quick hack is probably going to be the
"right" thing for this case.

> > diff -r 5fa9b746d24f -r 510c6bceb87f 
> > linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c
> > --- a/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c     Sat Sep 02 
> > 12:11:54 2006 +0100
> > +++ b/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c     Sat Sep 02 
> > 15:11:17 2006 -0400
> > @@ -1866,8 +1866,12 @@ void __init setup_arch(char **cmdline_p)
> >  #endif
> >  #endif
> >     } else {
> > +#if defined(CONFIG_VT) && defined(CONFIG_DUMMY_CONSOLE)
> > +           conswitchp = &dummy_con;
> > +#else
> >             extern int console_use_vt;
> >             console_use_vt = 0;
> > +#endif
> >     }
> >  }
> Not quite sure I understand what this is trying to achieve, or why it's
> related to the PV framebuffer stuff.

It makes it so that console switching is achieved by the dummy console
and then when the fbcon driver is loaded, it takes over.  

[snip]
> Perhaps XEN_KEYBOARD should depend on XEN_FRAMEBUFFER, given that it
> doesn't work without it.

Yeah, seems reasonable enough -- I've added to my tree.

> >  config XEN_SCRUB_PAGES
> >     bool "Scrub memory before freeing it to Xen"
> >     default y
> > diff -r 5fa9b746d24f -r 510c6bceb87f 
> > linux-2.6-xen-sparse/drivers/xen/Makefile
> > --- a/linux-2.6-xen-sparse/drivers/xen/Makefile     Sat Sep 02 12:11:54 
> > 2006 +0100
> > +++ b/linux-2.6-xen-sparse/drivers/xen/Makefile     Sat Sep 02 15:11:17 
> > 2006 -0400
> > @@ -15,3 +15,5 @@ obj-$(CONFIG_XEN_NETDEV_FRONTEND) += net
> >  obj-$(CONFIG_XEN_NETDEV_FRONTEND)  += netfront/
> >  obj-$(CONFIG_XEN_PCIDEV_BACKEND)   += pciback/
> >  obj-$(CONFIG_XEN_PCIDEV_FRONTEND)  += pcifront/
> > +obj-$(CONFIG_XEN_FRAMEBUFFER)              += xenfb/
> > +obj-$(CONFIG_XEN_KEYBOARD)         += xenkbd/
> > diff -r 5fa9b746d24f -r 510c6bceb87f linux-2.6-xen-sparse/mm/memory.c
> > --- a/linux-2.6-xen-sparse/mm/memory.c      Sat Sep 02 12:11:54 2006 +0100
> > +++ b/linux-2.6-xen-sparse/mm/memory.c      Sat Sep 02 15:11:17 2006 -0400
> > @@ -881,6 +881,7 @@ unsigned long zap_page_range(struct vm_a
> >             tlb_finish_mmu(tlb, address, end);
> >     return end;
> >  }
> > +EXPORT_SYMBOL(zap_page_range);
> It's unfortunate that we have to modify an upstream file here, but I
> can't really see any alternative.

Well, if we don't allow the framebuffer to be modular then it doesn't
have to be exported.  But that also seems like the wrong answer :-)

> > +#if 0
> > +        /* if we're not set up to use graphics mode, then don't initialize 
> > */
> > +   if (xenbus_scanf(XBT_NIL, "console", "use_graphics", "%d", &ret) < 0)
> > +           return -ENODEV;
> > +   if (ret == 0)
> > +           return -ENODEV;
> > +#endif
> That's interesting.  What is this here for?

It looks like it got accidentally #if 0'd while merging patches.
Whoops.  Basically, if the guest isn't set up to use a graphical
console, then we shouldn't initialize the devices.

Jeremy


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.