On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
Amit,
Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback. From
there, when an interrupt occurs, the stack looks something like this:
So on a CONSOLE_PORT_ADD message, we would take the
(existing)ports_device::ports_lock, and for other control messages we
would justtake the (new) port::port_lock? You are concerned that just
takingthe ports_lock for all control messages could be too
restrictive? Iwouldn't have expected these
On (Mon) 12 Dec 2011 [11:11:55], Miche Baker-Harvey wrote:
So on a CONSOLE_PORT_ADD message, we would take the
(existing)ports_device::ports_lock, and for other control messages we
would justtake the (new) port::port_lock? You are concerned that just
takingthe ports_lock for all control
On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
Amit,
Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback. From
there, when an interrupt occurs, the stack looks something like this:
Amit,
Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback. From
there, when an interrupt occurs, the stack looks something like this:
virtio_pci::vp_interrupt()
virtio_pci::vp_vring_interrupt()
On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
Good grief! Sorry for the spacing mess-up! Here's a resend with
reformatting.
Amit,
We aren't using either QEMU or kvmtool, but we are using KVM. All
So it's a different userspace? Any chance this different userspace is
causing
Hi,
On (Mon) 28 Nov 2011 [15:40:41], Miche Baker-Harvey wrote:
Amit,
You said that the work would be serialized due to port additions
being on work items on the same workqueue. I'm not seeing that.
You leave a lot of questions unanswered. What's your environment?
Are you hot-plugging
Amit,
We aren't using either QEMU or kvmtool, but we are using KVM. All
theissues we are seeing happen when we try to establish multiple
virtioconsoles at boot time. The command line isn't relevant, but I
cantell you the protocol that's passing between the host (kvm) and
theguest (see the end of
Good grief! Sorry for the spacing mess-up! Here's a resend with reformatting.
Amit,
We aren't using either QEMU or kvmtool, but we are using KVM. All
the issues we are seeing happen when we try to establish multiple
virtioconsoles at boot time. The command line isn't relevant, but I
can tell
Amit,
You said that the work would be serialized due to port additions
being on work items on the same workqueue. I'm not seeing that.
I've double checked this by using a mutex_trylock in
hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
root@myubuntu:~# dmesg | grep MBH
On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
Rusty, Michael, Stephen, et al,
Thanks for your comments on these patches.
For what I'm trying to do, all three patches are necessary, but maybe
I'm going about it the wrong way. Your input would be appreciated.
I'm in no way
On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
With this setup, with and without patches, I can spawn two consoles
via:
/sbin/agetty /dev/hvc0 9600 vt100
/sbin/agetty /dev/hvc1 9600 vt100
(Strange thing is, the second one gives a 'password incorrect' error
on login attempts, while the
On (Wed) 23 Nov 2011 [15:06:04], Sasha Levin wrote:
On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
With this setup, with and without patches, I can spawn two consoles
via:
/sbin/agetty /dev/hvc0 9600 vt100
/sbin/agetty
On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
With this setup, with and without patches, I can spawn two consoles
via:
/sbin/agetty /dev/hvc0 9600 vt100
/sbin/agetty /dev/hvc1 9600 vt100
(Strange thing is, the second one
Thanks, Rusty. I'm not using QEMU though, just KVM. I create the device, wait
for the message from the guest that the device is ready, and then add ports.
Miche
On Sun, Nov 20, 2011 at 9:01 PM, Rusty Russell ru...@rustcorp.com.au wrote:
On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey
On Mon, 21 Nov 2011 14:16:38 -0800, Miche Baker-Harvey mi...@google.com wrote:
Thanks, Rusty. I'm not using QEMU though, just KVM. I create the device,
wait
for the message from the guest that the device is ready, and then add ports.
Miche
OK, since Amit was the one who implemented
Rusty, Michael, Stephen, et al,
Thanks for your comments on these patches.
For what I'm trying to do, all three patches are necessary, but maybe
I'm going about it the wrong way. Your input would be appreciated.
I'm in no way claiming that these patches are right, just that it's
working for me,
On Tue, 08 Nov 2011 13:45:04 -0800, Miche Baker-Harvey mi...@google.com wrote:
hvc_init() must only be called once, and no thread should continue with
hvc_alloc()
until after initialization is complete. The original code does not enforce
either
of these requirements. A new mutex limits
hvc_init() must only be called once, and no thread should continue with
hvc_alloc()
until after initialization is complete. The original code does not enforce
either
of these requirements. A new mutex limits entry to hvc_init() to a single
thread,
and blocks all later comers until it has
On Tue, 2011-11-08 at 13:45 -0800, Miche Baker-Harvey wrote:
hvc_init() must only be called once, and no thread should continue with
hvc_alloc()
until after initialization is complete. The original code does not enforce
either
of these requirements. A new mutex limits entry to hvc_init()
20 matches
Mail list logo
