* Re: [PATCH 0/8] virtio: console: Fixes, cleanups, stats for bytes transferred
From: Amit Shah @ 2011-10-31 10:19 UTC (permalink / raw)
To: Rusty Russell; +Cc: Juan Quintela, Virtualization List
In-Reply-To: <cover.1315985553.git.amit.shah@redhat.com>
On (Wed) 14 Sep 2011 [13:06:38], Amit Shah wrote:
> Hello,
>
> These patches are mostly cleanups (patches 1, 4, 5, 6, 7). Patches 2
> and 3 fix cases which will be exposed when S4 support is enabled.
>
> Patch 8 adds stats for bytes received, sent and discarded for each
> port. These are added for debugging data loss issues (rather,
> pointing out they don't exist). Closing a port while data transfer is
> ongoing resulted in discarding of any pending data in the vq, which is
> the expected case. Adding these stats just helps showing there's no
> data loss, but things are working as they were designed.
>
> Please apply.
Hey Rusty,
Can you push this series to Linus for 3.2? Thanks!
Amit
^ permalink raw reply
* Re: [PATCH 0/1] virtio: console: fix for early console
From: Amit Shah @ 2011-10-31 10:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: Christian Borntraeger, kvm list, Virtualization List
In-Reply-To: <cover.1316715093.git.amit.shah@redhat.com>
On (Thu) 22 Sep 2011 [23:44:22], Amit Shah wrote:
> Hi Rusty,
>
> This is a fix from Christian for early console handling with multiport
> support. Please apply.
>
> Christian, I've made some changes to the patch as noted in the commit
> message. Nothing major, but an ACK would be nice.
>
> Thanks.
Hey Rusty can you push this fix for 3.2?
Thanks
Amit
^ permalink raw reply
* Re: [PATCHv4] virtio-blk: use ida to allocate disk index
From: Rusty Russell @ 2011-10-31 23:55 UTC (permalink / raw)
To: Jens Axboe, Michael S. Tsirkin
Cc: Tejun Heo, Greg Kroah-Hartman, linux-kernel, kvm, virtualization
In-Reply-To: <4EAE48D3.4090504@kernel.dk>
On Mon, 31 Oct 2011 08:05:55 +0100, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-10-30 20:29, Michael S. Tsirkin wrote:
> > Based on a patch by Mark Wu <dwu@redhat.com>
> >
> > Current index allocation in virtio-blk is based on a monotonically
> > increasing variable "index". This means we'll run out of numbers
> > after a while. It also could cause confusion about the disk
> > name in the case of hot-plugging disks.
> > Change virtio-blk to use ida to allocate index, instead.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > Changes from Mark's versions:
> > use the new ida_simple_get
> > error handling cleanup
> > fix user after free
> >
> > Works fine for me.
> >
> > Jens, could you merge this for 3.2?
> > That is, unless Rusty complains shortly ...
>
> Yep, tentatively added.
Thanks!
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 0/8] virtio: console: Fixes, cleanups, stats for bytes transferred
From: Rusty Russell @ 2011-10-31 23:57 UTC (permalink / raw)
To: Amit Shah; +Cc: Juan Quintela, Virtualization List
In-Reply-To: <20111031101940.GC3557@amit-x200.redhat.com>
On Mon, 31 Oct 2011 15:49:40 +0530, Amit Shah <amit.shah@redhat.com> wrote:
> On (Wed) 14 Sep 2011 [13:06:38], Amit Shah wrote:
> > Hello,
> >
> > These patches are mostly cleanups (patches 1, 4, 5, 6, 7). Patches 2
> > and 3 fix cases which will be exposed when S4 support is enabled.
> >
> > Patch 8 adds stats for bytes received, sent and discarded for each
> > port. These are added for debugging data loss issues (rather,
> > pointing out they don't exist). Closing a port while data transfer is
> > ongoing resulted in discarding of any pending data in the vq, which is
> > the expected case. Adding these stats just helps showing there's no
> > data loss, but things are working as they were designed.
> >
> > Please apply.
>
> Hey Rusty,
>
> Can you push this series to Linus for 3.2? Thanks!
Yep, was going to do it yesterday but spent the day chasing console
breakage in lguest, but it's not caused by these.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PULL] virtio
From: Michael S. Tsirkin @ 2011-11-01 11:45 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
Christian Borntraeger, Sasha Levin, Amit Shah, Linus Torvalds
In-Reply-To: <87wrbkvh3v.fsf@rustcorp.com.au>
On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote:
> * [new tag] rusty@rustcorp.com.au-v3.1-7196-gac5be1e -> rusty@rustcorp.com.au-v3.1-7196-gac5be1e
>
> The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d:
>
> Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30 15:54:59 -0700)
>
> are available in the git repository at:
>
> git://github.com/rustyrussell/linux.git master
>
> Alexey Kardashevskiy (1):
> virtio-pci: Use PCI MMIO instead of PIO when available
I missed this one - wasn't Cc'd neither me, kvm or virtio mailing lists.
It's well known that mmio is much slower than pio on kvm, since
mmio needs to be emulated to get at the address.
So I'm expecting this will cause a performance regression.
IMO we should keep using PIO for VQ and interrupt status access
if PIO is available.
Another consideration is that in an attempt to pack data
densely in the PIO space the layout became messy.
It would be better to have common config space and
per-device config space in separate pages, possibly
with padding between them.
So I'd like a bit more discussion on this patch,
I'm concerned that if this is released in 3.2 as is we'll
have to support this forever. How about a revert for now?
> Amit Shah (8):
> virtio: console: Fix indentation
> virtio: console: Ignore port name update request if name already set
> virtio: console: Use wait_event_freezable instead of _interruptible
> virtio: console: Fix return type for get_inbuf()
> virtio: console: make get_inbuf() return port->inbuf if present
> virtio: console: rename variable
> virtio: console: make discard_port_data() use get_inbuf()
> virtio: console: add port stats for bytes received, sent and discarded
>
> Christian Borntraeger (1):
> virtio: console: wait for first console port for early console output
>
> Krishna Kumar (1):
> virtio: Dont add "config" to list for !per_vq_vector
>
> Michael S. Tsirkin (1):
> virtio-blk: use ida to allocate disk index
>
> Pawel Moll (1):
> virtio: Add platform bus driver for memory mapped virtio device
>
> Sasha Levin (3):
> virtio-console: Use virtio_config_val() for retrieving config
> virtio_config: Add virtio_config_val_len()
> virtio-net: Use virtio_config_val() for retrieving config
>
> Wang Sheng-Hui (2):
> virtio.h: correct comment for struct virtio_driver
> virtio: modify vring_init and vring_size to take account of the layout containing *_event_idx
>
> Documentation/devicetree/bindings/virtio/mmio.txt | 17 +
> drivers/block/virtio_blk.c | 30 +-
> drivers/char/virtio_console.c | 120 ++++--
> drivers/net/virtio_net.c | 14 +-
> drivers/virtio/Kconfig | 11 +
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio_mmio.c | 479 +++++++++++++++++++++
> drivers/virtio/virtio_pci.c | 20 +-
> include/linux/virtio.h | 4 +-
> include/linux/virtio_config.h | 3 +
> include/linux/virtio_mmio.h | 111 +++++
> include/linux/virtio_ring.h | 6 +-
> 12 files changed, 749 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/virtio/mmio.txt
> create mode 100644 drivers/virtio/virtio_mmio.c
> create mode 100644 include/linux/virtio_mmio.h
^ permalink raw reply
* Re: [PULL] virtio
From: Sasha Levin @ 2011-11-01 12:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <20111101114542.GA13434@redhat.com>
On Tue, 2011-11-01 at 13:45 +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote:
> > * [new tag] rusty@rustcorp.com.au-v3.1-7196-gac5be1e -> rusty@rustcorp.com.au-v3.1-7196-gac5be1e
> >
> > The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d:
> >
> > Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30 15:54:59 -0700)
> >
> > are available in the git repository at:
> >
> > git://github.com/rustyrussell/linux.git master
> >
> > Alexey Kardashevskiy (1):
> > virtio-pci: Use PCI MMIO instead of PIO when available
>
> I missed this one - wasn't Cc'd neither me, kvm or virtio mailing lists.
>
> It's well known that mmio is much slower than pio on kvm, since
> mmio needs to be emulated to get at the address.
> So I'm expecting this will cause a performance regression.
> IMO we should keep using PIO for VQ and interrupt status access
> if PIO is available.
>
> Another consideration is that in an attempt to pack data
> densely in the PIO space the layout became messy.
> It would be better to have common config space and
> per-device config space in separate pages, possibly
> with padding between them.
>
> So I'd like a bit more discussion on this patch,
> I'm concerned that if this is released in 3.2 as is we'll
> have to support this forever. How about a revert for now?
Another thing, the patch tries to map BAR 2 and use it as the
configuration space.
It's both not documented properly anywhere, and is not fully backwards
compatible - we currently use BAR 2 as part of our MSIX handling in the
kvm tool and I'm sure we're not the only ones to assume virtio-pci only
uses BAR 0.
A proper solution would be for example a configuration in the PIO config
space which points to the MMIO BAR to use instead.
Unless Michael pointed this patch out, it would have broken (at least)
the kvm tool in a non obvious way which would require a rather long
session of 'git bisect' to figure out whats wrong.
--
Sasha.
^ permalink raw reply
* Re: [PULL] virtio
From: Michael S. Tsirkin @ 2011-11-01 12:42 UTC (permalink / raw)
To: Sasha Levin
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <1320150813.3847.24.camel@lappy>
On Tue, Nov 01, 2011 at 02:33:33PM +0200, Sasha Levin wrote:
> On Tue, 2011-11-01 at 13:45 +0200, Michael S. Tsirkin wrote:
> > On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote:
> > > * [new tag] rusty@rustcorp.com.au-v3.1-7196-gac5be1e -> rusty@rustcorp.com.au-v3.1-7196-gac5be1e
> > >
> > > The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d:
> > >
> > > Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30 15:54:59 -0700)
> > >
> > > are available in the git repository at:
> > >
> > > git://github.com/rustyrussell/linux.git master
> > >
> > > Alexey Kardashevskiy (1):
> > > virtio-pci: Use PCI MMIO instead of PIO when available
> >
> > I missed this one - wasn't Cc'd neither me, kvm or virtio mailing lists.
> >
> > It's well known that mmio is much slower than pio on kvm, since
> > mmio needs to be emulated to get at the address.
> > So I'm expecting this will cause a performance regression.
> > IMO we should keep using PIO for VQ and interrupt status access
> > if PIO is available.
> >
> > Another consideration is that in an attempt to pack data
> > densely in the PIO space the layout became messy.
> > It would be better to have common config space and
> > per-device config space in separate pages, possibly
> > with padding between them.
> >
> > So I'd like a bit more discussion on this patch,
> > I'm concerned that if this is released in 3.2 as is we'll
> > have to support this forever. How about a revert for now?
>
> Another thing, the patch tries to map BAR 2 and use it as the
> configuration space.
>
> It's both not documented properly anywhere, and is not fully backwards
> compatible - we currently use BAR 2 as part of our MSIX handling in the
> kvm tool and I'm sure we're not the only ones to assume virtio-pci only
> uses BAR 0.
>
> A proper solution would be for example a configuration in the PIO config
> space which points to the MMIO BAR to use instead.
I think it makes sense to put the configuration in PCI
configuration space, using vendor-specific capability.
This way we can reuse existing functionality for scanning
capability lists.
> Unless Michael pointed this patch out, it would have broken (at least)
> the kvm tool in a non obvious way which would require a rather long
> session of 'git bisect' to figure out whats wrong.
>
> --
>
> Sasha.
^ permalink raw reply
* Re: [PULL] virtio
From: Sasha Levin @ 2011-11-01 12:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <20111101124223.GA14060@redhat.com>
On Tue, 2011-11-01 at 14:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 01, 2011 at 02:33:33PM +0200, Sasha Levin wrote:
> > On Tue, 2011-11-01 at 13:45 +0200, Michael S. Tsirkin wrote:
> > > On Tue, Nov 01, 2011 at 10:39:08AM +1030, Rusty Russell wrote:
> > > > * [new tag] rusty@rustcorp.com.au-v3.1-7196-gac5be1e -> rusty@rustcorp.com.au-v3.1-7196-gac5be1e
> > > >
> > > > The following changes since commit 839d8810747bbf39e0a5a7f223b67bffa7945f8d:
> > > >
> > > > Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (2011-10-30 15:54:59 -0700)
> > > >
> > > > are available in the git repository at:
> > > >
> > > > git://github.com/rustyrussell/linux.git master
> > > >
> > > > Alexey Kardashevskiy (1):
> > > > virtio-pci: Use PCI MMIO instead of PIO when available
> > >
> > > I missed this one - wasn't Cc'd neither me, kvm or virtio mailing lists.
> > >
> > > It's well known that mmio is much slower than pio on kvm, since
> > > mmio needs to be emulated to get at the address.
> > > So I'm expecting this will cause a performance regression.
> > > IMO we should keep using PIO for VQ and interrupt status access
> > > if PIO is available.
> > >
> > > Another consideration is that in an attempt to pack data
> > > densely in the PIO space the layout became messy.
> > > It would be better to have common config space and
> > > per-device config space in separate pages, possibly
> > > with padding between them.
> > >
> > > So I'd like a bit more discussion on this patch,
> > > I'm concerned that if this is released in 3.2 as is we'll
> > > have to support this forever. How about a revert for now?
> >
> > Another thing, the patch tries to map BAR 2 and use it as the
> > configuration space.
> >
> > It's both not documented properly anywhere, and is not fully backwards
> > compatible - we currently use BAR 2 as part of our MSIX handling in the
> > kvm tool and I'm sure we're not the only ones to assume virtio-pci only
> > uses BAR 0.
> >
> > A proper solution would be for example a configuration in the PIO config
> > space which points to the MMIO BAR to use instead.
>
> I think it makes sense to put the configuration in PCI
> configuration space, using vendor-specific capability.
> This way we can reuse existing functionality for scanning
> capability lists.
Yup, I agree. It would also allow dropping the PIO config BAR altogether
after some period of backwards compatibility.
It was mostly to point out that the patch isn't really backwards
compatible :)
--
Sasha.
^ permalink raw reply
* Additional virtio-mmio spec changes
From: Pawel Moll @ 2011-11-01 13:01 UTC (permalink / raw)
To: Rusty Russell; +Cc: Peter Maydell, linux-kernel, virtualization
Hi Rusty,
Peter (on Cc) got the qemu implementation up and running (thanks!) and
provided some useful feedback regarding the spec. To make the long story
short, this is what came out of the discussion (feel free to correct me
at any point, Peter ;-):
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index 6426f8f..79a6498 100644
--- a/virtio-spec.lyx
+++ b/virtio-spec.lyx
@@ -6681,7 +6681,9 @@ s on QueueNum, QueueAlign and QueuePFN apply to.
Writing to this register notifies the Host what size of the queue the Guest
will use.
- This applies to the queue selected by writing to QueueSel.
+ This applies to the queue selected by writing to QueueSel and is allowed
+ only when QueuePFN is set to zero (0x0), so when the queue is not actively
+ used.
\end_layout
@@ -6790,8 +6792,8 @@ This interrupt is asserted when configuration of the device has changed.
Writing to this register notifies the Host that the Guest finished handling
interrupts.
- Every bit of the value clears corresponding bit of the InterruptStatus
- register.
+ Set bits in the value clear the corresponding bits of the
+ InterruptStatus register.
\end_layout
@@ -6975,7 +6977,9 @@ reference "sub:Notifying-The-Device"
\end_layout
\begin_layout Enumerate
-The memory mapped virtio device is using single, dedicated interrupt signal.
+The memory mapped virtio device is using single, dedicated interrupt signal,
+ which is raised when at least one of the interrupts described in the
+ InterruptStatus register description is asserted.
After receiving an interrupt, the driver must read the InterruptStatus
register to check what caused the interrupt (see the register description).
After the interrupt is handled, the driver must acknowledge it by writing
Of course those changes are not critical so can easily wait till the
next release. Peter also mentioned that he didn't like the "Num" in
"QueueNum" register name and would rather see it called "QueueSize". I
have no strong opinions either way and can provide patches to both the
spec and the driver (and header) to change it. Any thoughts?
Cheers!
Paweł
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [PULL] virtio
From: Rusty Russell @ 2011-11-02 1:09 UTC (permalink / raw)
To: Michael S. Tsirkin, Sasha Levin
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <20111101124223.GA14060@redhat.com>
On Tue, 1 Nov 2011 14:42:23 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Nov 01, 2011 at 02:33:33PM +0200, Sasha Levin wrote:
> > A proper solution would be for example a configuration in the PIO config
> > space which points to the MMIO BAR to use instead.
>
> I think it makes sense to put the configuration in PCI
> configuration space, using vendor-specific capability.
> This way we can reuse existing functionality for scanning
> capability lists.
Patch welcome; first one to implement it becomes virtio PCI maintainer!
I'll keep maintaining the spec, since it covers much more than the PCI
mechanics, but everything I know about PCI I learn from these
discussions.
Meanwhile, I've dropped this patch; mea culpa.
> > Unless Michael pointed this patch out, it would have broken (at least)
> > the kvm tool in a non obvious way which would require a rather long
> > session of 'git bisect' to figure out whats wrong.
I assumed not, until QEMU provided the second BAR it would simply fall
back. Or am I completely misunderstanding?
Thanks,
Rusty.
^ permalink raw reply
* Re: Regression: patch " hvc_console: display printk messages on console." causing infinite loop with 3.2-rc0 + Xen.
From: Stephen Rothwell @ 2011-11-02 1:13 UTC (permalink / raw)
To: Greg KH
Cc: xen-devel, Konrad Rzeszutek Wilk, Benjamin Herrenschmidt, miche,
linux-kernel, virtualization, Linus, Anton Blanchard, Amit Shah,
ppc-dev
In-Reply-To: <20111027054806.GA1377@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1152 bytes --]
Hi Greg,
On Thu, 27 Oct 2011 07:48:06 +0200 Greg KH <gregkh@suse.de> wrote:
>
> On Thu, Oct 27, 2011 at 01:30:08AM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey Miche.
> >
> > The git commit 361162459f62dc0826b82c9690a741a940f457f0:
> >
> > hvc_console: display printk messages on console.
> >
> > is causing an infinite loop when booting Linux under Xen, as so:
>
> Ick, not good, thanks for letting us know.
Indeed. I am wondering why it was put in a tree and sent to Linus without
any Acks or even being replied to by anyone. It appeared in the tty tree
between Oct 14 and Oct 25 (while I was unfortunately on vacation). If
anyone had tried to boot this on any PowerPC server, it would have been
immediately obvious (as it was when I booted Linus' tree last night).
And the original author expressed doubts as to his understanding of how
it should all work anyway.
Just a little more care, please.
I would vote for reverting the original and having it resubmitted with
corrections at some later date.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: Additional virtio-mmio spec changes
From: Rusty Russell @ 2011-11-02 1:21 UTC (permalink / raw)
To: Pawel Moll; +Cc: Peter Maydell, linux-kernel, virtualization
In-Reply-To: <1320152499.3287.197.camel@hornet.cambridge.arm.com>
On Tue, 01 Nov 2011 13:01:39 +0000, Pawel Moll <pawel.moll@arm.com> wrote:
> Hi Rusty,
>
> Peter (on Cc) got the qemu implementation up and running (thanks!) and
> provided some useful feedback regarding the spec. To make the long story
> short, this is what came out of the discussion (feel free to correct me
> at any point, Peter ;-):
OK, I applied them manually. One of the pains of using LyX is that you
need to turn change tracking on before making changes (I really like to
produce change-tracking versions of new spec releases).
> Of course those changes are not critical so can easily wait till the
> next release. Peter also mentioned that he didn't like the "Num" in
> "QueueNum" register name and would rather see it called "QueueSize". I
> have no strong opinions either way and can provide patches to both the
> spec and the driver (and header) to change it. Any thoughts?
Num isn't great, but Size might be misleading. I'd leave it...
Thanks,
Rusty.
^ permalink raw reply
* Re: [PULL] virtio
From: Sasha Levin @ 2011-11-02 4:52 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, kvm, Pawel Moll, Michael S. Tsirkin,
Alexey Kardashevskiy, Wang Sheng-Hui, lkml - Kernel Mailing List,
virtualization, Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <8739e7uy87.fsf@rustcorp.com.au>
On Wed, 2011-11-02 at 11:39 +1030, Rusty Russell wrote:
> On Tue, 1 Nov 2011 14:42:23 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Tue, Nov 01, 2011 at 02:33:33PM +0200, Sasha Levin wrote:
> > > Unless Michael pointed this patch out, it would have broken (at least)
> > > the kvm tool in a non obvious way which would require a rather long
> > > session of 'git bisect' to figure out whats wrong.
>
> I assumed not, until QEMU provided the second BAR it would simply fall
> back. Or am I completely misunderstanding?
QEMU uses two bars within each virtio-pci device. First one (BAR 0) is
the PIO config BAR, and the second one (BAR 1) is the MSI-X BAR used for
the MSI-X table and the PBA.
Since the PCI spec allows you to have the MSI-X table and the PBA in
completely different regions pointed by two different BARs, we did so in
kvm tools and have BAR 1 pointing to the MSI-X table, and BAR 2 pointing
to the PBA ( - we *already* provided the second BAR and used it for
something else).
This means that with this patch, we'd load BAR 2 and use it as the
config space, instead of the PBA table which it really represents.
--
Sasha.
^ permalink raw reply
* Re: Additional virtio-mmio spec changes
From: Peter Maydell @ 2011-11-02 13:31 UTC (permalink / raw)
To: Pawel Moll, Rusty Russell; +Cc: linux-kernel, virtualization
Rusty wrote:
>Pawel Moll <pawel.moll@arm.com> wrote:
>> Peter also mentioned that he didn't like the "Num" in
>> "QueueNum" register name and would rather see it called "QueueSize". I
>> have no strong opinions either way and can provide patches to both the
>> spec and the driver (and header) to change it. Any thoughts?
>
> Num isn't great, but Size might be misleading. I'd leave it...
I'd note that calling it QueueNum is inconsistent with the main
virtio spec, which calls the equivalent virtio header field
"Queue Size". Also if the docs say
"QueueNum
Virtual queue size.
Queue size is a number of elements in the queue [...]"
this rather suggests to me that we've picked the wrong name for
the register...
-- PMM
^ permalink raw reply
* virtio-pci new configuration proposal
From: Sasha Levin @ 2011-11-02 18:49 UTC (permalink / raw)
To: Rusty Russell, Michael S. Tsirkin; +Cc: linux-kernel, kvm, virtualization
This is a proposal for a new layout of the virtio-pci config space.
We will separate the current configuration into two: A virtio-pci common
configuration and a device specific configuration. This allows more flexibility
with adding features and makes usage easier, specifically in cases like the
ones in virtio-net where device specific configurations depend on device
specific features.
The preferred location of the configuration will be a MMIO BAR, therefore
several size optimizations such as the queue selector which were useful
on a PIO BAR were removed and linked lists were introduced to add
flexibility to existing structures in attempt to keep their size and
offsets constant and not dependent on features.
While this is not a complete specification, it describes all the main
structures and should be enough to make sure the idea is solid before
going into implementation specifics.
A new virtio-pci capability structure will be introduced. This structure
will be used to describe the basics of a virtio-pci device. The
structure is actually a PCI capability structure which wraps the new virtio-pci
capability structure:
+------------++------------+------------+------------+--------------+-----------------
| Bits || 8 | 8 | 8 | 8 | Cap specific
+------------++------------+------------+------------+--------------+-----------------
| Read/Write || R | R | R | R | Cap specific
+------------++------------+------------+------------+--------------+-----------------
| Purpose || Capability | Capability | virtio-pci | virtio-pci | Cap specific
| || ID | Next PTR | Cap ID | Next Cap PTR |
+------------++------------+------------+------------+--------------+-----------------
Currently, only one virtio-pci capability is defined, and is the one that defines
the layout of the virtio-pci config space.
VIRTIO_PCI_C_LAYOUT:
+------------++---------------+---------------+-----------------+-----------------+
| Bits || 29 | 3 | 29 | 3 |
+------------++---------------+---------------+-----------------+-----------------+
| Read/Write || R | R | R | R |
+------------++---------------+---------------+-----------------+-----------------+
| Purpose || Common config | Common config | Device specific | Device specific |
| || Offset | BIR | Offset | BIR |
+------------++---------------+---------------+-----------------+-----------------+
The combination of the offset and the BIR will point to the common and device
specific configuration spaces. These spaces may be pointed to by the same, or
by different BARs and may sit in the same or different MMIO regions.
The BIR is a PCI concept which describes which BAR should be used:
"Indicates which one of a function’s Base Address registers, located beginning
at 10h in Configuration space, is used to map the function’s MSI-X Table into
memory space.
BIR Value Base Address register
0 10h
1 14h
2 18h
3 1Ch
4 20h
5 24h
6 Reserved
7 Reserved"
While the offset will provide a 32-bit aligned offset into the memory region
and will point to the appropriate config space.
First, we will look at the virtio-pci configuration space, which has been
simplified from the original.
virtio-pci header:
+------------++---------+--------+--------------+--------------+
| Bits || 8 | 8 | 16 | 16 |
+------------++---------+--------+--------------+--------------+
| Read/Write || R+W | R | R | R |
+------------++---------+--------+--------------+--------------+
| Purpose || Device | ISR | Queue | virtio-pci |
| || Status | Status | Table Ptr | Features Ptr |
+------------++---------+--------+--------------+--------------+
Device and ISR status are the same as in the original, and two new fields
have been added. Queue table ptr is an offset from the beginning of the
config space to a table which describes all virtio queues, and is defined
below.
Virtio-pci features ptr will point to virtio-pci features, such features
will be placed in a virtio-pci feature struct which is defined as follows:
virtio-pci features:
+------------++------------+------------+-------------------
| Bits || 8 | 16 | Feature specific
+------------++------------+------------+-------------------
| Read/Write || R | R | Feature specific
+------------++------------+------------+-------------------
| Purpose || Feature | Feature | Feature specific
| || ID | Next PTR |
+------------++------------+------------+-------------------
For example, the virtio-pci MSI-X feature will look as follows:
VIRTIO_PCI_F_MSIX:
+------------++----------------+
| Bits || 16 |
+------------++----------------+
| Read/Write || R+W |
+------------++----------------+
| Purpose || Configuration |
| || Vector |
+------------++----------------+
The queue table is the table which will hold the definition of all virtio
queues. The virtio queue selector has been dropped and instead the queues
are listed in a simple list:
Queue table:
+------------++-------------------+--------+---------+--------------+--------------
| Bits || 8 | 32 | 16 | 16 | 16 | More queues
+------------++-------------------+--------+---------+--------------+--------------
| Read/Write || R | R+W | R | R+W | R | More queues
+------------++-------------------+--------+---------+--------------+--------------
| Purpose || Queue | Queue | Queue | Queue | Queue | More queues
| || Count | Address | Size | Notify | Features Ptr |
+------------++-------------------+--------+---------+--------------+--------------
Besides the usual fields, each virtio queue will also have a feature ptr which
points to queue specific features. These features may be shared between queues
therefore it is not required to define a feature struct for each queue.
Queue features:
+------------++------------+------------+-------------------
| Bits || 8 | 16 | Feature specific
+------------++------------+------------+-------------------
| Read/Write || R | R | Feature specific
+------------++------------+------------+-------------------
| Purpose || Feature | Feature | Feature specific
| || ID | Next PTR |
+------------++------------+------------+-------------------
For example, the virtio queue MSI-X feature will look as follows and may be
shared between all virtio queues if we only have one vector for all queues.
VIRTIO_QUEUE_F_MSIX:
+------------++--------+
| Bits || 16 |
+------------++--------+
| Read/Write || R+W |
+------------++--------+
| Purpose || Queue |
| (MSI-X) || Vector |
+------------++--------+
The second part is the device specific configuration space. This is
basically a linked list of features which may be activated or
deactivated by setting the active flag in each feature.
Device specific features:
+------------++------------+------------+----------+---------
| Bits || 8 | 16 | 8 | Feature specific
+------------++------------+------------+----------+---------
| Read/Write || R | R | R+W | Feature specific
+------------++------------+------------+----------+---------
| Purpose || Feature | Feature | Feature | Feature specific
| || ID | Next PTR | Active |
+------------++------------+------------+----------+---------
For example, the virtio-net MAC feature will look as follows:
VIRTIO_NET_F_MAC:
+------------++------------+
| Bits || 48 |
+------------++------------+
| Read/Write || R |
+------------++------------+
| Purpose || virtio-net |
| || MAC |
+------------++------------+
--
Sasha.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH RFC 0/2] virtio-pci: polling mode support
From: Michael S. Tsirkin @ 2011-11-02 19:02 UTC (permalink / raw)
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, Jan Kiszka,
virtualization, Blue Swirl, Stefan Weil, Avi Kivity,
Richard Henderson
MSIX spec requires that device can be operated with
all vectors masked, by polling.
So the following patchset (lightly tested) adds this
ability: when driver reads ISR, the device
recalls a pending notification, and returns
pending status in the ISR register.
The polling driver can operate as follows:
- map all VQs and config to the same vector
- poll ISR to get status - this also flushes VQ updates to memory
- handle config change or VQ event depending on ISR
Comments?
--
1.7.5.53.gc233e
^ permalink raw reply
* Re: virtio-pci new configuration proposal
From: Sasha Levin @ 2011-11-02 19:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, kvm, virtualization
In-Reply-To: <20111102190804.GA13914@redhat.com>
On Wed, 2011-11-02 at 21:08 +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 02, 2011 at 08:49:27PM +0200, Sasha Levin wrote:
> > This is a proposal for a new layout of the virtio-pci config space.
> >
> > We will separate the current configuration into two: A virtio-pci common
> > configuration and a device specific configuration. This allows more flexibility
> > with adding features and makes usage easier, specifically in cases like the
> > ones in virtio-net where device specific configurations depend on device
> > specific features.
> >
> > The preferred location of the configuration will be a MMIO BAR, therefore
> > several size optimizations such as the queue selector which were useful
> > on a PIO BAR were removed and linked lists were introduced to add
> > flexibility to existing structures in attempt to keep their size and
> > offsets constant and not dependent on features.
> >
> > While this is not a complete specification, it describes all the main
> > structures and should be enough to make sure the idea is solid before
> > going into implementation specifics.
> >
> > A new virtio-pci capability structure will be introduced. This structure
> > will be used to describe the basics of a virtio-pci device. The
> > structure is actually a PCI capability structure which wraps the new virtio-pci
> > capability structure:
> >
> > +------------++------------+------------+------------+--------------+-----------------
> > | Bits || 8 | 8 | 8 | 8 | Cap specific
> > +------------++------------+------------+------------+--------------+-----------------
> > | Read/Write || R | R | R | R | Cap specific
> > +------------++------------+------------+------------+--------------+-----------------
> > | Purpose || Capability | Capability | virtio-pci | virtio-pci | Cap specific
> > | || ID | Next PTR | Cap ID | Next Cap PTR |
> > +------------++------------+------------+------------+--------------+-----------------
> >
> > Currently, only one virtio-pci capability is defined, and is the one that defines
> > the layout of the virtio-pci config space.
> >
> > VIRTIO_PCI_C_LAYOUT:
> >
> > +------------++---------------+---------------+-----------------+-----------------+
> > | Bits || 29 | 3 | 29 | 3 |
> > +------------++---------------+---------------+-----------------+-----------------+
> > | Read/Write || R | R | R | R |
> > +------------++---------------+---------------+-----------------+-----------------+
> > | Purpose || Common config | Common config | Device specific | Device specific |
> > | || Offset | BIR | Offset | BIR |
> > +------------++---------------+---------------+-----------------+-----------------+
>
> I'm implementing a different layout, with
> separate capabilities for common and device specific
> fields.
Which is what I have here, no?
--
Sasha.
^ permalink raw reply
* Re: virtio-pci new configuration proposal
From: Michael S. Tsirkin @ 2011-11-02 19:08 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, kvm, virtualization
In-Reply-To: <1320259767.22582.2.camel@lappy>
On Wed, Nov 02, 2011 at 08:49:27PM +0200, Sasha Levin wrote:
> This is a proposal for a new layout of the virtio-pci config space.
>
> We will separate the current configuration into two: A virtio-pci common
> configuration and a device specific configuration. This allows more flexibility
> with adding features and makes usage easier, specifically in cases like the
> ones in virtio-net where device specific configurations depend on device
> specific features.
>
> The preferred location of the configuration will be a MMIO BAR, therefore
> several size optimizations such as the queue selector which were useful
> on a PIO BAR were removed and linked lists were introduced to add
> flexibility to existing structures in attempt to keep their size and
> offsets constant and not dependent on features.
>
> While this is not a complete specification, it describes all the main
> structures and should be enough to make sure the idea is solid before
> going into implementation specifics.
>
> A new virtio-pci capability structure will be introduced. This structure
> will be used to describe the basics of a virtio-pci device. The
> structure is actually a PCI capability structure which wraps the new virtio-pci
> capability structure:
>
> +------------++------------+------------+------------+--------------+-----------------
> | Bits || 8 | 8 | 8 | 8 | Cap specific
> +------------++------------+------------+------------+--------------+-----------------
> | Read/Write || R | R | R | R | Cap specific
> +------------++------------+------------+------------+--------------+-----------------
> | Purpose || Capability | Capability | virtio-pci | virtio-pci | Cap specific
> | || ID | Next PTR | Cap ID | Next Cap PTR |
> +------------++------------+------------+------------+--------------+-----------------
>
> Currently, only one virtio-pci capability is defined, and is the one that defines
> the layout of the virtio-pci config space.
>
> VIRTIO_PCI_C_LAYOUT:
>
> +------------++---------------+---------------+-----------------+-----------------+
> | Bits || 29 | 3 | 29 | 3 |
> +------------++---------------+---------------+-----------------+-----------------+
> | Read/Write || R | R | R | R |
> +------------++---------------+---------------+-----------------+-----------------+
> | Purpose || Common config | Common config | Device specific | Device specific |
> | || Offset | BIR | Offset | BIR |
> +------------++---------------+---------------+-----------------+-----------------+
I'm implementing a different layout, with
separate capabilities for common and device specific
fields.
^ permalink raw reply
* Re: virtio-pci new configuration proposal
From: Michael S. Tsirkin @ 2011-11-02 19:14 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, kvm, virtualization
In-Reply-To: <1320260832.22582.3.camel@lappy>
On Wed, Nov 02, 2011 at 09:07:12PM +0200, Sasha Levin wrote:
> On Wed, 2011-11-02 at 21:08 +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 02, 2011 at 08:49:27PM +0200, Sasha Levin wrote:
> > > This is a proposal for a new layout of the virtio-pci config space.
> > >
> > > We will separate the current configuration into two: A virtio-pci common
> > > configuration and a device specific configuration. This allows more flexibility
> > > with adding features and makes usage easier, specifically in cases like the
> > > ones in virtio-net where device specific configurations depend on device
> > > specific features.
> > >
> > > The preferred location of the configuration will be a MMIO BAR, therefore
> > > several size optimizations such as the queue selector which were useful
> > > on a PIO BAR were removed and linked lists were introduced to add
> > > flexibility to existing structures in attempt to keep their size and
> > > offsets constant and not dependent on features.
> > >
> > > While this is not a complete specification, it describes all the main
> > > structures and should be enough to make sure the idea is solid before
> > > going into implementation specifics.
> > >
> > > A new virtio-pci capability structure will be introduced. This structure
> > > will be used to describe the basics of a virtio-pci device. The
> > > structure is actually a PCI capability structure which wraps the new virtio-pci
> > > capability structure:
> > >
> > > +------------++------------+------------+------------+--------------+-----------------
> > > | Bits || 8 | 8 | 8 | 8 | Cap specific
> > > +------------++------------+------------+------------+--------------+-----------------
> > > | Read/Write || R | R | R | R | Cap specific
> > > +------------++------------+------------+------------+--------------+-----------------
> > > | Purpose || Capability | Capability | virtio-pci | virtio-pci | Cap specific
> > > | || ID | Next PTR | Cap ID | Next Cap PTR |
> > > +------------++------------+------------+------------+--------------+-----------------
> > >
> > > Currently, only one virtio-pci capability is defined, and is the one that defines
> > > the layout of the virtio-pci config space.
> > >
> > > VIRTIO_PCI_C_LAYOUT:
> > >
> > > +------------++---------------+---------------+-----------------+-----------------+
> > > | Bits || 29 | 3 | 29 | 3 |
> > > +------------++---------------+---------------+-----------------+-----------------+
> > > | Read/Write || R | R | R | R |
> > > +------------++---------------+---------------+-----------------+-----------------+
> > > | Purpose || Common config | Common config | Device specific | Device specific |
> > > | || Offset | BIR | Offset | BIR |
> > > +------------++---------------+---------------+-----------------+-----------------+
> >
> > I'm implementing a different layout, with
> > separate capabilities for common and device specific
> > fields.
>
> Which is what I have here, no?
No :) Give me a couple of hours I'll send an RFC patch so you can see
what I mean.
> --
>
> Sasha.
^ permalink raw reply
* [PATCH (repost) RFC 1/2] virtio: ISR bit constants
From: Michael S. Tsirkin @ 2011-11-02 20:11 UTC (permalink / raw)
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, Jan Kiszka,
virtualization, Blue Swirl, Stefan Weil, Avi Kivity,
Richard Henderson
In-Reply-To: <cover.1320259840.git.mst@redhat.com>
Add constants for ISR bits values, and use them in virtio.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
hw/virtio.c | 7 ++++---
hw/virtio.h | 5 +++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 7011b5b..74627e4 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -672,7 +672,7 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int queue_size,
void virtio_irq(VirtQueue *vq)
{
trace_virtio_irq(vq);
- vq->vdev->isr |= 0x01;
+ vq->vdev->isr |= VIRTIO_ISR_VQ;
virtio_notify_vector(vq->vdev, vq->vector);
}
@@ -717,7 +717,7 @@ void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
}
trace_virtio_notify(vdev, vq);
- vdev->isr |= 0x01;
+ vdev->isr |= VIRTIO_ISR_VQ;
virtio_notify_vector(vdev, vq->vector);
}
@@ -726,7 +726,8 @@ void virtio_notify_config(VirtIODevice *vdev)
if (!(vdev->status & VIRTIO_CONFIG_S_DRIVER_OK))
return;
- vdev->isr |= 0x03;
+ /* TODO: why do we set VIRTIO_ISR_VQ here? */
+ vdev->isr |= VIRTIO_ISR_VQ | VIRTIO_ISR_CONFIG;
virtio_notify_vector(vdev, vdev->config_vector);
}
diff --git a/hw/virtio.h b/hw/virtio.h
index 2d18209..1bb6210 100644
--- a/hw/virtio.h
+++ b/hw/virtio.h
@@ -54,6 +54,11 @@
/* A guest should never accept this. It implies negotiation is broken. */
#define VIRTIO_F_BAD_FEATURE 30
+/* The bit of the ISR which indicates a device vq event. */
+#define VIRTIO_ISR_VQ 0x1
+/* The bit of the ISR which indicates a device configuration change. */
+#define VIRTIO_ISR_CONFIG 0x2
+
/* from Linux's linux/virtio_ring.h */
/* This marks a buffer as continuing via the next field. */
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH (repost) RFC 2/2] virtio-pci: recall and return msix notifications on ISR read
From: Michael S. Tsirkin @ 2011-11-02 20:11 UTC (permalink / raw)
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, Jan Kiszka,
virtualization, Blue Swirl, Stefan Weil, Avi Kivity,
Richard Henderson
In-Reply-To: <cover.1320259840.git.mst@redhat.com>
MSIX spec requires that device can be operated with
all vectors masked, by polling pending bits.
Add APIs to recall an msix notification, and make polling
mode possible in virtio-pci by clearing the
pending bits and setting ISR appropriately on ISR read.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
hw/msix.c | 26 ++++++++++++++++++++++++++
hw/msix.h | 3 +++
hw/virtio-pci.c | 11 ++++++++++-
3 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 63b41b9..fe967c9 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -349,6 +349,32 @@ void msix_notify(PCIDevice *dev, unsigned vector)
stl_le_phys(address, data);
}
+/* Recall outstanding MSI-X notifications for a vector, if possible.
+ * Return true if any were outstanding. */
+bool msix_recall(PCIDevice *dev, unsigned vector)
+{
+ bool ret;
+ if (vector >= dev->msix_entries_nr)
+ return false;
+ ret = msix_is_pending(dev, vector);
+ msix_clr_pending(dev, vector);
+ return ret;
+}
+
+/* Recall outstanding MSI-X notifications for all vectors, if possible.
+ * Return true if any were outstanding. */
+bool msix_recall_all(PCIDevice *dev)
+{
+ uint8_t ret = 0;
+ uint8_t *b;
+ for (b = dev->msix_table_page + MSIX_PAGE_PENDING;
+ b <= msix_pending_byte(dev, dev->msix_entries_nr - 1); ++b) {
+ ret |= *b;
+ *b = 0;
+ }
+ return ret;
+}
+
void msix_reset(PCIDevice *dev)
{
if (!(dev->cap_present & QEMU_PCI_CAP_MSIX))
diff --git a/hw/msix.h b/hw/msix.h
index 7e04336..86a92b1 100644
--- a/hw/msix.h
+++ b/hw/msix.h
@@ -27,6 +27,9 @@ void msix_unuse_all_vectors(PCIDevice *dev);
void msix_notify(PCIDevice *dev, unsigned vector);
+bool msix_recall(PCIDevice *dev, unsigned vector);
+bool msix_recall_all(PCIDevice *dev);
+
void msix_reset(PCIDevice *dev);
extern int msix_supported;
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index df27c19..cab7dde 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -393,7 +393,16 @@ static uint32_t virtio_ioport_read(VirtIOPCIProxy *proxy, uint32_t addr)
/* reading from the ISR also clears it. */
ret = vdev->isr;
vdev->isr = 0;
- qemu_set_irq(proxy->pci_dev.irq[0], 0);
+ if (msix_enabled(&proxy->pci_dev)) {
+ if (msix_recall(&proxy->pci_dev, vdev->config_vector)) {
+ ret |= VIRTIO_ISR_CONFIG;
+ }
+ if (msix_recall_all(&proxy->pci_dev)) {
+ ret |= VIRTIO_ISR_VQ;
+ }
+ } else {
+ qemu_set_irq(proxy->pci_dev.irq[0], 0);
+ }
break;
case VIRTIO_MSI_CONFIG_VECTOR:
ret = vdev->config_vector;
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: [PATCH] VirtioConsole support.
From: Rusty Russell @ 2011-11-02 22:02 UTC (permalink / raw)
To: Stephen Boyd, Joe Perches
Cc: xen-devel, Konrad Rzeszutek Wilk, Benjamin Herrenschmidt,
Greg Kroah-Hartman, Miche Baker-Harvey, linux-kernel,
virtualization, Christian Borntraeger, Hendrik Brueckner,
Anton Blanchard, Amit Shah
In-Reply-To: <4EAAF23C.8050102@codeaurora.org>
On Fri, 28 Oct 2011 11:19:40 -0700, Stephen Boyd <sboyd@codeaurora.org> wrote:
> Even better would be kmemdup().
OK, this driver is horribly unloved, and ugly. Noone claims to really
understand it, but people keep poking it.
Ben, Christian, can you figure out what's going on? Is it time for a
complete rewrite?
Thanks,
Rusty.
^ permalink raw reply
* Re: [PULL] virtio
From: Rusty Russell @ 2011-11-02 22:07 UTC (permalink / raw)
To: Sasha Levin
Cc: Krishna Kumar, kvm, Pawel Moll, Michael S. Tsirkin,
Alexey Kardashevskiy, Wang Sheng-Hui, lkml - Kernel Mailing List,
virtualization, Christian Borntraeger, Amit Shah, Linus Torvalds
In-Reply-To: <1320209564.9173.6.camel@lappy>
On Wed, 02 Nov 2011 06:52:44 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> Since the PCI spec allows you to have the MSI-X table and the PBA in
> completely different regions pointed by two different BARs, we did so in
> kvm tools and have BAR 1 pointing to the MSI-X table, and BAR 2 pointing
> to the PBA ( - we *already* provided the second BAR and used it for
> something else).
Got it! Thanks for the explanation.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH RFC 0/3] Support multiple VirtioConsoles.
From: Miche Baker-Harvey @ 2011-11-02 22:19 UTC (permalink / raw)
To: Stephen Rothwell, Greg Kroah-Hartman, Konrad Rzeszutek Wilk,
Benjamin Herrenschmidt, Rusty
This patchset applies to linux-next/next-20111102.
This series implements support for multiple virtio_consoles using KVM.
This patchset addresses several issues associated with trying to
establish multiple virtio consoles.
I'm trying to start a guest via KVM that supports multiple virtual
consoles, with getty's on each, and with some being console devices.
These patches let me establish more than one VirtioConsole (I'm
running eight at the moment), and enable console output appearing on
one of them. It still doesn't successfully generate console output on
multiple VirtioConsoles.
Let me apologise for my last patch having gotten into Linus' tree, and
leaving other people to deal with crashes. I had meant to be asking
for guidance, but I didn't mark it as "RFC".
This series reflects the input from Konrad Rzeszutek, Amit Shah, Stephen
Boyd, and Rusty Russell. I think we do have to limit hvc_alloc() to one
thread.
I would appreciate any comments or feedback, or accept if appropriate.
Thanks,
Miche Baker-Harvey
---
Miche Baker-Harvey (3):
virtio_console: Fix locking of vtermno.
hvc_init(): Enforce one-time initialization.
Use separate struct console structure for each hvc_console.
drivers/char/virtio_console.c | 9 ++++++---
drivers/tty/hvc/hvc_console.c | 33 +++++++++++++++++++++++++++++++--
drivers/tty/hvc/hvc_console.h | 1 +
3 files changed, 38 insertions(+), 5 deletions(-)
--
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Move the mouse driver out of staging
From: Jesper Juhl @ 2011-11-02 22:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: K. Y. Srinivasan, dmitry.torokhov, jkosina, gregkh, ohering,
linux-kernel, virtualization, joe, devel
In-Reply-To: <20111029063240.GH14881@longonot.mountain>
On Sat, 29 Oct 2011, Dan Carpenter wrote:
> On Sat, Oct 29, 2011 at 12:54:34AM +0200, Jesper Juhl wrote:
> > > + default:
> > > + pr_err("unhandled packet type %d, tid %llx len %d\n",
> > > + desc->type,
> > > + req_id,
> > > + bytes_recvd);
> >
> > Why not:
> >
> > pr_err("unhandled packet type %d, tid %llx
> > len %d\n", desc->type, req_id, bytes_recvd);
>
> Because then the printk would be messed up? Your final printed
> string would look like:
>
> "unhandled packet type %d, tid %llx
> len %d\n"
>
> Don't break strings up across lines because it breaks grep. If K. Y.
> wants to put all the parameters on one line instead of three that
> would probably be better, but in the end who cares?
>
Right, so I obviously "fat fingered" that and should have read my email
once more before sending. *But* the point really was just the "put all the
parameters on one line rather than 3" bit...
As for who cares; well, I cared enough to actually read the patch and send
a reply, and I thought we needed more reviewers... When I review something
I comment on everything I spot from bugs to trivial stuff - then it is
up to the recipient to pick the things they want to address from the
reply..
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox