Re: [kvm-devel] [PATCH/PFC 0/2] s390 host support

[Carsten O. <co...@de...>]

Avi Kivity wrote:
> Carsten Otte wrote:
>> No, we did not have the need to do that. Now that you mention it, we'd 
>> want to move interprocessor signal handling into the kernel anyway for 
>> performance reasons. That would rise the need to wake up from kernel. 
>> The other way round, how do you intend to wake a thread that uses 
>> poll() or similar from userspace?
>>
> 
> Write to a pipe, or send a signal (signals are quite fast if you mask 
> them in userspace and use ppoll()).
Signals have the disadvantage that they wake all guest CPUs (unless 
one dedicates a singal per vcpu which does'nt scale). I think we need 
a wakeup mechanism that can be used to send an interrupt to a specific 
idle cpu from both kernel and userland. Pipes and poll (one per cpu) 
would allow that, but it seems to me like there must be better options.
After having slept over it, I think that our idle/wakeup mechanism for 
s390host is a mess. I will try to come up with an idea for this.

 > I don't know what your usage model is, but it seems to me that
 > leaving the host userspace at the mercy of the guest is a fairly
 > large security hole:
 > - the guest can modify the user's files, and read other users' files
 > - the guest can access the host's network, possibly bypassing any
 > firewalling that is set up for the guest
 > - the guest can access other virtual machines on the host
 >
 > So, if the guest is broken into, or if you download an untrusted
 > guest image ("virtual appliance"), then potentially large amounts of
 > data are at risk, even if you run as a regular user.  Does your
 > usage model allow this?
Okay, I am convinced. We need to secure both. That will cause some 
rework of our IO device drivers we use in our prototype, which don't 
exactly care to check input data from the guest in userspace today.
Also, I am going to figure why kvm does'nt to run non-root in my local 
x86 installation.

so long,
Carsten