On 07/25/2011 03:26 PM, Sasha Levin wrote:
>
> You can't block when a signal is pending. You can block, however, after
> you've exited with -EINTR and re-entered.
>
What would happen with the MMIO then? I need to provide an answer before
I leave the read/write functions to exit with -EINTR, n
On Mon, 2011-07-25 at 15:16 +0300, Avi Kivity wrote:
> On 07/25/2011 03:10 PM, Sasha Levin wrote:
> > On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
> > > Second, introducing a new type of exit doesn't mean we see more exits.
> > >
> > > Third, the new type of exit is probably not needed -
On 07/25/2011 03:10 PM, Sasha Levin wrote:
On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
> Second, introducing a new type of exit doesn't mean we see more exits.
>
> Third, the new type of exit is probably not needed - we can use the
> existing mmio/pio exits, and document that in certa
On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
> Second, introducing a new type of exit doesn't mean we see more exits.
>
> Third, the new type of exit is probably not needed - we can use the
> existing mmio/pio exits, and document that in certain cases the kernel
> will fall back to these
On 07/20/2011 04:44 AM, Pekka Enberg wrote:
On Tue, 2011-07-19 at 21:49 -0500, Anthony Liguori wrote:
If you're not going to emulate a UART properly, why not just use a
paravirtual serial device that you can keep simple?
We want to emulate it correctly to make it robust. The problems you
point
On Tue, 2011-07-19 at 21:49 -0500, Anthony Liguori wrote:
> If you're not going to emulate a UART properly, why not just use a
> paravirtual serial device that you can keep simple?
We want to emulate it correctly to make it robust. The problems you
pointed out were caused by me being under heavy
On Wed, 2011-07-20 at 09:16 +0300, Sasha Levin wrote:
> > Just implement virtio-serial :-) You can move data as fast as you'd
> > like through it.
> >
> > And if virtio-serial is too complicated, make a simpler version that
> > doesn't have such crazy semantics.
>
> We do have virtio-serial su
On 07/20/2011 05:42 AM, Anthony Liguori wrote:
I suspect a normal uart is a bad use case for this.
The THR can only hold a single value, a guest is not supposed to write
to the THR again until the THRE flag in the LSR is set which indicates
that the THR is empty.
In fact, when THRE is raise
On Tue, 2011-07-19 at 21:52 -0500, Anthony Liguori wrote:
> On 07/14/2011 08:23 AM, Avi Kivity wrote:
> > On 07/14/2011 04:17 PM, Pekka Enberg wrote:
> >> >
> >> > I still don't follow. The guest oopses? dmesg | less. An issue with
> >> > tools/kvm? gdb -p `pgrep kvm`.
> >>
> >> When I was debuggin
On 07/14/2011 08:23 AM, Avi Kivity wrote:
On 07/14/2011 04:17 PM, Pekka Enberg wrote:
>
> I still don't follow. The guest oopses? dmesg | less. An issue with
> tools/kvm? gdb -p `pgrep kvm`.
When I was debugging tools/kvm virtio code, I used to 'instrument' the
guest kernel with printk() calls
On 07/13/2011 02:07 AM, Avi Kivity wrote:
On 07/13/2011 09:45 AM, Pekka Enberg wrote:
>
> OK, what's the simplest thing we can do here to keep Avi happy and get
> the functionality of Sasha's original patch that helps us avoid guest
> exits for serial console? I agree with Avi that we don't want
On 07/05/2011 11:37 PM, Sasha Levin wrote:
The new flag allows passing a connected socket instead of an
eventfd to be notified of writes or reads to the specified memory region.
Instead of signaling an event, On write - the value written to the memory
region is written to the pipe.
On read - a n
On 07/14/2011 04:17 PM, Pekka Enberg wrote:
>
> I still don't follow. The guest oopses? dmesg | less. An issue with
> tools/kvm? gdb -p `pgrep kvm`.
When I was debugging tools/kvm virtio code, I used to 'instrument' the
guest kernel with printk() calls which helped a lot.
Sure, but do you
On Thu, 2011-07-14 at 16:05 +0300, Avi Kivity wrote:
> On 07/14/2011 04:00 PM, Sasha Levin wrote:
> > >
> > > Why? virtio is mature. It's not some early boot thing which fails and
> > > kills the guest. Even if you get an oops, usually the guest is still
> > > alive.
> >
> > virtio is mature,
On 07/14/2011 04:00 PM, Sasha Levin wrote:
>
> Why? virtio is mature. It's not some early boot thing which fails and
> kills the guest. Even if you get an oops, usually the guest is still alive.
virtio is mature, /tools/kvm isn't :)
>
> > It's not just virtio which can fail running on vir
On Thu, 2011-07-14 at 15:46 +0300, Avi Kivity wrote:
> On 07/14/2011 03:32 PM, Sasha Levin wrote:
> > On Thu, 2011-07-14 at 14:54 +0300, Avi Kivity wrote:
> > > On 07/14/2011 01:30 PM, Pekka Enberg wrote:
> > > > We want to use 8250 emulation instead of virtio-serial because it's
> > > > more
On 07/14/2011 03:52 PM, Pekka Enberg wrote:
On Thu, 2011-07-14 at 15:48 +0300, Avi Kivity wrote:
> Use virtio-console when you're in production (it will be much much
> faster than socket-mmio 8250), and 8250 when debugging.
This is exactly what we try to avoid. We want to use same code for
pro
On Thu, 2011-07-14 at 15:48 +0300, Avi Kivity wrote:
> Use virtio-console when you're in production (it will be much much
> faster than socket-mmio 8250), and 8250 when debugging.
This is exactly what we try to avoid. We want to use same code for
production and debugging when possible. And btw, w
On 07/14/2011 03:37 PM, Pekka Enberg wrote:
Hi Avi,
On Thu, Jul 14, 2011 at 2:54 PM, Avi Kivity wrote:
>> I don't think it needs to be faster for *significant number* of users
>> but yes, I completely agree that we need to make sure KVM gains more
>> than the costs are.
>
> Significant, for
On 07/14/2011 03:32 PM, Sasha Levin wrote:
On Thu, 2011-07-14 at 14:54 +0300, Avi Kivity wrote:
> On 07/14/2011 01:30 PM, Pekka Enberg wrote:
> > We want to use 8250 emulation instead of virtio-serial because it's
> > more compatible with kernel debugging mechanisms. Also, it makes
> > deb
Hi Avi,
On Thu, Jul 14, 2011 at 2:54 PM, Avi Kivity wrote:
>> I don't think it needs to be faster for *significant number* of users
>> but yes, I completely agree that we need to make sure KVM gains more
>> than the costs are.
>
> Significant, for me, means it's measured in a percentage, not as d
On Thu, 2011-07-14 at 14:54 +0300, Avi Kivity wrote:
> On 07/14/2011 01:30 PM, Pekka Enberg wrote:
> > We want to use 8250 emulation instead of virtio-serial because it's
> > more compatible with kernel debugging mechanisms. Also, it makes
> > debugging virtio code much easier when we don't need to
On 07/14/2011 01:30 PM, Pekka Enberg wrote:
Hi Avi,
On Thu, Jul 14, 2011 at 12:48 PM, Avi Kivity wrote:
>> Why does that matter? Why should we keep the emulation slow if it's
>> possible to fix it?
>
> Fixing things that don't need fixing has a cost. In work, in risk, and in
> maintainabil
Hi Avi,
On Thu, Jul 14, 2011 at 12:48 PM, Avi Kivity wrote:
>> Why does that matter? Why should we keep the emulation slow if it's
>> possible to fix it?
>
> Fixing things that don't need fixing has a cost. In work, in risk, and in
> maintainability. If you can share this cost among other users
On 07/14/2011 11:59 AM, Pekka Enberg wrote:
On Thu, Jul 14, 2011 at 11:28 AM, Avi Kivity wrote:
> On 07/14/2011 11:14 AM, Pekka Enberg wrote:
>>
>> >
>> >I'm talking about the real world. Is any of this something that needs
>> >optimization?
>>
>> Yes. See Sasha's other email. We s
On Thu, Jul 14, 2011 at 11:28 AM, Avi Kivity wrote:
> On 07/14/2011 11:14 AM, Pekka Enberg wrote:
>>
>> >
>> > I'm talking about the real world. Is any of this something that needs
>> > optimization?
>>
>> Yes. See Sasha's other email. We should have mentioned that in the
>> changelog.
>
> It's
On 07/14/2011 11:25 AM, Michael S. Tsirkin wrote:
On Thu, Jul 14, 2011 at 11:09:57AM +0300, Avi Kivity wrote:
> I'm talking about the real world. Is any of this something that
> needs optimization?
This work might help enable vhost support for non-MSI guests
(required for linux 2.6.30 and bac
On 07/14/2011 11:14 AM, Pekka Enberg wrote:
>
> I'm talking about the real world. Is any of this something that needs
> optimization?
Yes. See Sasha's other email. We should have mentioned that in the changelog.
It's completely unrealistic. Sash and you are the only two people in
the univ
On Thu, Jul 14, 2011 at 11:09:57AM +0300, Avi Kivity wrote:
> I'm talking about the real world. Is any of this something that
> needs optimization?
This work might help enable vhost support for non-MSI guests
(required for linux 2.6.30 and back). It's not enough
for that though: we would also nee
On Thu, Jul 14, 2011 at 11:09:57AM +0300, Avi Kivity wrote:
> On 07/14/2011 10:26 AM, Pekka Enberg wrote:
> >
> >On 7/13/11 4:32 PM, Avi Kivity wrote:
> >>Just how fast do you type?
> >>
> >>It's not enough to make something faster, it has to be slow to
> >>being with. The interface is good, but u
On Thu, Jul 14, 2011 at 11:09 AM, Avi Kivity wrote:
> On 07/14/2011 10:26 AM, Pekka Enberg wrote:
>>
>> On 7/13/11 4:32 PM, Avi Kivity wrote:
>>>
>>> Just how fast do you type?
>>>
>>> It's not enough to make something faster, it has to be slow to being
>>> with. The interface is good, but use it
On 07/14/2011 10:26 AM, Pekka Enberg wrote:
On 7/13/11 4:32 PM, Avi Kivity wrote:
Just how fast do you type?
It's not enough to make something faster, it has to be slow to being
with. The interface is good, but use it where it helps.
I don't know why you bring up serial console input here.
On Thu, 2011-07-14 at 10:26 +0300, Pekka Enberg wrote:
> On 07/13/2011 04:00 PM, Pekka Enberg wrote:
> >> On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
> >> >> We'd like to keep 8250 emulation because it's the most robust method
> >> >> for getting data out of the kernel when there's proble
On 07/13/2011 04:00 PM, Pekka Enberg wrote:
On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
>> We'd like to keep 8250 emulation because it's the most robust method
>> for getting data out of the kernel when there's problems. It's also
>> compatible with earlyprintk and such.
>
> What do y
On 07/13/2011 04:00 PM, Pekka Enberg wrote:
On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
>> We'd like to keep 8250 emulation because it's the most robust method
>> for getting data out of the kernel when there's problems. It's also
>> compatible with earlyprintk and such.
>
> What do y
On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
>> We'd like to keep 8250 emulation because it's the most robust method
>> for getting data out of the kernel when there's problems. It's also
>> compatible with earlyprintk and such.
>
> What do you hope to gain from the optimization? 100ms less
On 07/13/2011 11:02 AM, Pekka Enberg wrote:
On Wed, Jul 13, 2011 at 10:07 AM, Avi Kivity wrote:
> - the writes are such high frequency that we gain something from the
> queueing is happens when we thread work. That's where the gain for serial
> console can come from - though it would be bett
On Wed, Jul 13, 2011 at 1:56 PM, Pekka Enberg wrote:
> On Wed, Jul 13, 2011 at 1:26 PM, Sasha Levin wrote:
>> The problem is that if we received a signal during the read notification
>> the write and before receiving the read, we have to go back to
>> userspace.
>>
>> This means that userspace wi
On Wed, Jul 13, 2011 at 1:26 PM, Sasha Levin wrote:
> The problem is that if we received a signal during the read notification
> the write and before receiving the read, we have to go back to
> userspace.
>
> This means that userspace will see same read request twice (once in the
> socket and once
On Wed, 2011-07-13 at 13:04 +0300, Pekka Enberg wrote:
> On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg wrote:
> > On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin
> > wrote:
> >> After working on that solution a bit I saw it's adding a lot of code and
> >> complexity for this small issue, and I'm n
On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg wrote:
> On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin wrote:
>> After working on that solution a bit I saw it's adding a lot of code and
>> complexity for this small issue, and I'm now thinking we may be better
>> off with just handling reads twice i
On Wed, Jul 13, 2011 at 10:07 AM, Avi Kivity wrote:
> - the writes are such high frequency that we gain something from the
> queueing is happens when we thread work. That's where the gain for serial
> console can come from - though it would be better to just use virtio-serial
> instead.
We'd lik
On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin wrote:
> After working on that solution a bit I saw it's adding a lot of code and
> complexity for this small issue, and I'm now thinking we may be better
> off with just handling reads twice in case of a signal just between
> socket_write() and socket_
On 07/13/2011 09:45 AM, Pekka Enberg wrote:
>
> OK, what's the simplest thing we can do here to keep Avi happy and get
> the functionality of Sasha's original patch that helps us avoid guest
> exits for serial console? I agree with Avi that we don't want
> fragmented ABI but it seems to me th
On Wed, Jul 13, 2011 at 9:37 AM, Pekka Enberg wrote:
> On 07/12/2011 02:23 PM, Sasha Levin wrote:
>>> > I don't insist on a new type of exit, just pointing out the problem.
>>>
>>> I agree with you, I don't have a better solution either.
>>>
>>> I don't feel it's worth it adding so much code for
Hi,
On 07/12/2011 02:23 PM, Sasha Levin wrote:
>> > I don't insist on a new type of exit, just pointing out the problem.
>>
>> I agree with you, I don't have a better solution either.
>>
>> I don't feel it's worth it adding so much code for read support to
>> properly work. Can we do this patch s
On 07/12/2011 02:23 PM, Sasha Levin wrote:
>
> I don't insist on a new type of exit, just pointing out the problem.
I agree with you, I don't have a better solution either.
I don't feel it's worth it adding so much code for read support to
properly work. Can we do this patch series without soc
On Sun, 2011-07-10 at 11:05 +0300, Michael S. Tsirkin wrote:
> On Sun, Jul 10, 2011 at 08:34:43AM +0300, Sasha Levin wrote:
> > On Wed, 2011-07-06 at 20:58 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 06, 2011 at 06:01:46PM +0300, Sasha Levin wrote:
> > > > On Wed, 2011-07-06 at 14:42 +0300,
On Sun, Jul 10, 2011 at 08:34:43AM +0300, Sasha Levin wrote:
> On Wed, 2011-07-06 at 20:58 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 06, 2011 at 06:01:46PM +0300, Sasha Levin wrote:
> > > On Wed, 2011-07-06 at 14:42 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 06, 2011 at 07:37:58AM
On Wed, 2011-07-06 at 20:58 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 06, 2011 at 06:01:46PM +0300, Sasha Levin wrote:
> > On Wed, 2011-07-06 at 14:42 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 06, 2011 at 07:37:58AM +0300, Sasha Levin wrote:
> > > > + if (p->sock) {
> > > > +
On Wed, Jul 06, 2011 at 06:01:46PM +0300, Sasha Levin wrote:
> On Wed, 2011-07-06 at 14:42 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 06, 2011 at 07:37:58AM +0300, Sasha Levin wrote:
> > > The new flag allows passing a connected socket instead of an
> > > eventfd to be notified of writes or r
On Wed, 2011-07-06 at 14:42 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 06, 2011 at 07:37:58AM +0300, Sasha Levin wrote:
> > The new flag allows passing a connected socket instead of an
> > eventfd to be notified of writes or reads to the specified memory region.
> >
> > Instead of signaling an
On 07/06/2011 03:58 PM, Sasha Levin wrote:
What about something as follows:
This requires an addition of a mutex to struct ioeventfd.
1. When adding a new ioeventfd, scan exiting ioeventfds (we already do
it anyway) and check whether another ioeventfd is using the socket
already.
2. If the exi
On 07/06/2011 07:37 AM, Sasha Levin wrote:
The new flag allows passing a connected socket instead of an
eventfd to be notified of writes or reads to the specified memory region.
Instead of signaling an event, On write - the value written to the memory
region is written to the pipe.
On read - a n
On Wed, 2011-07-06 at 15:39 +0300, Avi Kivity wrote:
> On 07/06/2011 07:37 AM, Sasha Levin wrote:
> > The new flag allows passing a connected socket instead of an
> > eventfd to be notified of writes or reads to the specified memory region.
> >
> > Instead of signaling an event, On write - the valu
On 07/06/2011 07:37 AM, Sasha Levin wrote:
The new flag allows passing a connected socket instead of an
eventfd to be notified of writes or reads to the specified memory region.
Instead of signaling an event, On write - the value written to the memory
region is written to the pipe.
On read - a n
On Wed, Jul 06, 2011 at 07:37:58AM +0300, Sasha Levin wrote:
> The new flag allows passing a connected socket instead of an
> eventfd to be notified of writes or reads to the specified memory region.
>
> Instead of signaling an event, On write - the value written to the memory
> region is written
The new flag allows passing a connected socket instead of an
eventfd to be notified of writes or reads to the specified memory region.
Instead of signaling an event, On write - the value written to the memory
region is written to the pipe.
On read - a notification of the read is sent to the host,
58 matches
Mail list logo
