Andrea Arcangeli wrote:
On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
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.
Again, a guest crash because of qlx interaction is not what I
mean. And the reason I wasn't even thinking about this scenario is
that the kind of paravirt-driver related guest crash you are talking
about, if it can happen, can happen even if spice lib in the qemu side
lives in a separate address space.
Yes, that's absolutely true.
This is why this case of pure guest
crash through qlx is not relevant to decide if to have spice lib
inside our outside of qemu address space, I think that is more about
the qlx driver and not spice on the qemu side.
The guest visible state thing has nothing to do with where it lives.
Sorry if that's gotten mixed in with this discussion.
The reason I care about what interacts directly with the guest is that
I'd like to see us move qemu to where there's a very strong separate
between guest-visible interactions and then host services to the point
where the portions of guest-visible code could be run in a highly secure
environment. If all of libspice would have to live in that environment
because it interacts with a guest directly, that would get complicated.
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
I would expect it to be ignorant about anything but qlx (what else
does it need to know), but I never looked into spice before it was
open source so it's not like I'm the right person to ask for those
details ;).
:-)
I'm really interested in those details.
Regards,
Anthony Liguori
