[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH] libxl: enabling upstream qemu as pure pv backend.
On Wed, 2011-06-08 at 14:00 +0100, Stefano Stabellini wrote: > On Wed, 8 Jun 2011, Ian Campbell wrote: > > > I don't think is a good idea to reset all these value to 0 here, > > > considering that the info parameter can be passed by the user. > > > It is better to use another libxl_device_model_info local variable and > > > just copy the very few fields we care about. > > > Otherwise in the stubdom case above you'll have the unwanted side effect > > > of removing useful informations of the stubdom from the structure. > > > > I think ideally the struct would be the same for both the PV and FV qemu > > and the device model create would only pay attention to the bits which > > fit the scenario (i.e. the PV case would ignore vcpus != 0, not zero > > it). > > > > This allows us to pass the same instance to both the PV and FV arg > > constructions routines in the stubdom+PV qemu case. > > I wouldn't be opposed to it. > The reason I didn't suggest to make this change now is that I see a > certain argument to keep the vfb settings separate, considering that vfb > can be thought as implementation independent protocol. Hmm, that's an interesting case, but I think: if qemu-for-PV guest: vfb args -> xenpv qemu (no brainer, it's the only one) if non-stub qemu-for-FV guest: vfb args -> xenfv qemu (no brainer, it's the only one) if stub qemu-for-FV guest: vfb args -> xenpv qemu process (what the user connects to) do the right thing internally args -> xenfv in stub domain IOW in the stub case the args for the stub FV qemu are an implementation detail within libxl. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |