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

Re: [Xen-devel] 32-on-64: pvfb issue



Markus Armbruster wrote:
> Gerd Hoffmann <kraxel@xxxxxxx> writes:
> 
>> and probably (hmm, does fc6 ship it?) not widely used yet that might be
>> an option.
> 
> Breaking the API now is right out of the question, I fear :)

Yep, I've seen in the release notes fc6 ships pvfb, so it is used in the
wild now and breaking the API is clearly out of question.  Damn.  Should
have reviewed the patches earlier ...

> You can evolve the API.  Let the frontend put something in xenstore[*]
> that lets the backend detect which page layout to use.  Make sure the
> backend can deal with old and new frontend.  I doubt it's worthwhile
> here.

Well, the problem are the *existing* guests, we already have two
different versions *without* indication out there:  The 32bit and the
64bit ones.  And with the upcoming 32-on-64 support the backend suddenly
must be able to deal with both of them.  Ideally it should work
automatically, without updating the frontends, and without manual
configuration.

> Excuse my ignorance, but why do you have to guess the guest's size?
> Doesn't dom0 know?

No, right now there is no hypercall to get that information.  Which
brings the discussion back onto the table:  Should we add one?  pvfb
isn't the only driver with that kind of problems.

And it better shouldn't be a dom0-only hypercall, otherwise driver
domains will not be able to use it ...

> [*] I suggested to put version ID right into the page, but that was
> shot down in favor of xenstore.

Too bad.  The configuration is in the shared page anyway, so what is the
point of *not* placing the version info there as well?

cheers,
  Gerd

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