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:
>
> virtio_pci::
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 me
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 mes
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:
>
> virtio_pci::
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()
virtio_ring::vring_
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
cau
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 y
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
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,
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
[33
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 s
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
> > > /
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, wh
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 wa
On Mon, 21 Nov 2011 14:16:38 -0800, Miche Baker-Harvey 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 multi-port conso
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 wrote:
> On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey
> wrote:
>> Rusty,
On Thu, 17 Nov 2011 10:57:37 -0800, 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 n
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 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_i
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_ini
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 compl
21 matches
Mail list logo