Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori <anthony@codemonkey.ws>]

Andrea Arcangeli wrote:
> On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote:
>   
>> If Spice can crash a guest, that indicates to me that Spice is 
>>     
>
> That's not what I meant, anything in qemu address space can crash a
> guest not just spice, even qcow2 could crash a guest, you just need to
> *vaddr_in_guest_physical_space = 0 through a corrupted pointer
> (corrupted pointers are very rare, gcc is very pedantic, there are
> tools to trap those but they historically happened a few times in the
> kernel), but when I said it I didn't in mind crashing just the guest,
> I meant corrupting qemu memory itself through a different corrupted
> vaddr, but it is the same risk, you could flip a bit in a buffer
> header holding ext4 metadata in the guest physical address space or
> flip a bit in qcow2 cluster bitmap, it doesn't make a difference both
> could result in fs corruption in an extremely unlikely scenario (and
> that extremely unlikely scenario is the only one where the microkernel
> design would eventually payoff, where you get the graphics and mouse
> hosed, but the guest sill is reachable through the network). I simply
> meant spice should live in the same address space where the other
> virtio drivers are living for the same reasons (performance), it's no
> different.

This is the bit that confuses me.  VNC is not a driver.  When I say it 
cannot crash the guest, I mean that if the VNC server makes a mistake, 
there may be a SEGV in qemu or it may just result in a VNC client seeing 
corruption.  The guest does not see a bad VGA register content though or 
something like that.  VNC is a host driver or backend service or 
whatever you want to call it.  VNC does not have migration state because 
it has no guest visible state.

When you compare Spice to a virtio driver, that implies to me that it 
does interact directly with the guest.  In fact, when you have a driver 
passing high level commands to Spice, you would think that the status of 
these commands would be pending state, no?

Let's say the guest sends a fill rectangle command and the Spice server 
sends that to a client.  The Spice server needs to know when the client 
has finished that (maybe not, but let's assume it does) so there is now 
a pending request that someone has to keep track of.  If you do a savevm 
or a live migration, or the client disconnects, the state of that 
request has to be saved somewhere (unless you tell the guest that the 
client has disconnected which is how Xen handles pv device migration).

So that's what I'm trying to understand.  How far does the guest's 
visibility go?  Is the guest totally ignorant of anything other than 
QXL?  If so, that's good, and I'm very happy about it :-)

Regards,

Anthony Liguori