[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |