I've never really thought much about them until now. What's the case
for supporting userspace hypercalls?
The current way the code works is a little scary. Hypercalls that
aren't handled by kernelspace are deferred to userspace. Of course,
kernelspace has no idea whether userspace is actually u
Anthony Liguori wrote:
> I've never really thought much about them until now. What's the case
> for supporting userspace hypercalls?
>
> The current way the code works is a little scary. Hypercalls that
> aren't handled by kernelspace are deferred to userspace. Of course,
> kernelspace has no id
Avi Kivity wrote:
> This means a pvnet driver can be used either directly
> with a virtual interface on the host, or having some userspace
> processing in qemu.
Also, 'qmu -net user -net model=pv' if you're unlucky enough not to have
root.
--
Any sufficiently difficult bug is indistinguishabl
Avi Kivity wrote:
> Anthony Liguori wrote:
>> I've never really thought much about them until now. What's the case
>> for supporting userspace hypercalls?
>>
>> The current way the code works is a little scary. Hypercalls that
>> aren't handled by kernelspace are deferred to userspace. Of course
Avi Kivity wrote:
>
> Thinking a little more about this, it isn't about handling hypercalls
> in userspace, but about handling a virtio sync() in userspace.
>
> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's
> event channel, but assymetric) that has a channel parameter. Th
On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote:
> Avi Kivity wrote:
> >
> > Thinking a little more about this, it isn't about handling hypercalls
> > in userspace, but about handling a virtio sync() in userspace.
> >
> > So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's
Anthony Liguori wrote:
> On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote:
>
>> Avi Kivity wrote:
>>
>>> Thinking a little more about this, it isn't about handling hypercalls
>>> in userspace, but about handling a virtio sync() in userspace.
>>>
>>> So how about having a KVM_HC_WAKE_CHA
On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote:
> >
> >> Avi Kivity wrote:
> >>
> >>> Thinking a little more about this, it isn't about handling hypercalls
> >>> in userspace, but about handling a virti
Anthony Liguori wrote:
> On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote:
>>>
>>>
Avi Kivity wrote:
> Thinking a little more about this, it isn't about hand
On Mon, 2007-08-27 at 20:51 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote:
> >
> > Yes, that would be better except that the latency may be unacceptable.
> >
> >
>
> Hmm. Good point. I keep saying kvm can have great I/O because th
On 8/27/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
> > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote:
> >> userspace can
> >> attach a signal to the eventfd if it wants a synchronous exit (does
> >> eventfd allow fcntl(F_SETOWN)?)
> >
> > Which would address the laten
Luca wrote:
> On 8/27/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Anthony Liguori wrote:
>>
>>> On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote:
>>>
userspace can
attach a signal to the eventfd if it wants a synchronous exit (does
eventfd allow fcntl(F_SETOWN)?
On Mon, 2007-08-27 at 23:01 +0300, Avi Kivity wrote:
> Luca wrote:
> >> if it isn't guaranteed to be the current thread, we're back
> >> with scheduler involvement, and possibly cacheline bouncing.
> >>
> >
> > It's possible to use pthread_sigmask() to block the signal on all
> > threads but
t;[EMAIL PROTECTED]>
Cc: kvm-devel <[EMAIL PROTECTED]>
To: Anthony Liguori <[EMAIL PROTECTED]>
Sent: 8/27/2007 10:47:22 AM
Subject: Re: [kvm-devel] Userspace hypercalls?
Avi Kivity wrote:
>
> Thinking a little more about this, it isn't about handling hypercalls
&g
>>> I've never really thought much about them until now. What's the
case
>>> for supporting userspace hypercalls?
>>>
>>> The current way the code works is a little scary. Hypercalls that
>>> aren't handled by kernelspace are deferred to userspace. Of course,
>>> kernelspace has no idea whether
Dor Laor wrote:
>>
>> Thinking a little more about this, it isn't about handling hypercalls
>>
> in
>
>> userspace, but about handling a virtio sync() in userspace.
>>
>> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's
>> event channel, but assymetric) that has a chann
16 matches
Mail list logo
