Re: [Xen-devel] [virtio-dev] Re: VIRTIO - compatibility with different virtualization solutions

["Michael S. Tsirkin" <mst@xxxxxxxxxx>]

On Mon, Mar 03, 2014 at 04:22:33PM +1030, Rusty Russell wrote:
> 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.
> 

It might be possible to allow adding new features with
an asynchronouse callback, e.g. after migration.
But what happens if you migrate to a different host that has less
features?
Device likely won't be able to proceed until features are negotiated,
so this makes it synchronous again.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: virtio-dev-help@xxxxxxxxxxxxxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel