[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.


>> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.