[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [virtio-dev] Re: VIRTIO - compatibility with different virtualization solutions
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes: > On Fri, Feb 21, 2014 at 11:24:14AM +1030, Rusty Russell wrote: >> Daniel Kiper <daniel.kiper@xxxxxxxxxx> writes: >> 2) In Linux, implement a virtio DMA ops which handles the grant table >> stuff for Xen (returning grant table ids + offset or something?), >> noop for others. This would be a runtime thing. > > Or perhaps an KVM specific DMA ops (which is nop) and Xen ops. > Easy enough to implement. Indeed. >> 3) In Linux, change the drivers to use this API. > > +1 >> >> Now, Xen will not be able to use vhost to accelerate, but it doesn't now >> anyway. > > Correct. Thought one could implement an ring of grant entries system > where the frontend and backend share it along with the hypervisor. > > And when the backend tries to access said memory thinking it has mapped > to the frontend (but it has not yet mapped this memory yet), it traps to > the hypervisor which then does mapping for the backend of the frontend > pages. Kind of lazy-grant system. > > Anyhow, all of that is just implementation details and hand-waving. It's unmap which is hard. You can do partial protection with lazy unmap, of course; it's a question of how strict you want your protection to be. > If we wanted we can extend vhost for when it plucks entries of the > virtq to call an specific platform API. For KVM it would be all > nops. For Xen it would do a magic pony show or such <more hand-waving>. > >> >> Am I missing anything? > > On a bit different topic: > > I am unclear about the asynchronous vs synchronous nature of Virt > configuration. > Xen is all about XenBus which is more of a callback mechanism. Virt does > its stuff on MMIO and PCI which are slow - but do get you the values. > > Can we somehow make it clear that the configuration setup can be asynchronous? > That would also mean that in the future this configuration (say when > migrating) > changes can be conveyed to the virtio frontends via an interrupt mechanism > (or callback) if the new host has something important to say? There are several options. One would be to add a XenBus transport for virtio (we already have PCI, mmio and CCW). But if you support PCI devices, you already deal with their synchronous nature. Cheers, Rusty. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |