similar to: [PATCH] virtio-pci: also bind to Amazon PCI vendor ID

Hi Michael, On Mon, Sep 15, 2014 at 1:20 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sun, Sep 14, 2014 at 08:29:33PM -0700, Anthony Liguori wrote: >> From: Anthony Liguori <aliguori at amazon.com> >> >> See https://issues.oasis-open.org/browse/VIRTIO-16 although it >> was prematurely closed. > > The reason it was closed is described in the

Hi Michael, On Mon, Sep 15, 2014 at 1:20 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sun, Sep 14, 2014 at 08:29:33PM -0700, Anthony Liguori wrote: >> From: Anthony Liguori <aliguori at amazon.com> >> >> See https://issues.oasis-open.org/browse/VIRTIO-16 although it >> was prematurely closed. > > The reason it was closed is described in the

From: Anthony Liguori <aliguori at amazon.com> If MSI-X initialization fails after setting msix_enabled = 1, then the device is left in an inconsistent state. This would normally only happen if there was a bug in the device emulation but it still should be handled correctly. Cc: Matt Wilson <msw at amazon.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Tsirkin

From: Anthony Liguori <aliguori at amazon.com> If MSI-X initialization fails after setting msix_enabled = 1, then the device is left in an inconsistent state. This would normally only happen if there was a bug in the device emulation but it still should be handled correctly. Cc: Matt Wilson <msw at amazon.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael Tsirkin

On Sun, Sep 14, 2014 at 08:29:33PM -0700, Anthony Liguori wrote: > From: Anthony Liguori <aliguori at amazon.com> > > See https://issues.oasis-open.org/browse/VIRTIO-16 although it > was prematurely closed. The reason it was closed is described in the comments. and I quote: " I think anyone can use a different subsystem vendor id and whql the driver. virtio-102 will make

Hi Michael, On Mon, Sep 15, 2014 at 1:32 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sun, Sep 14, 2014 at 08:23:26PM -0700, Anthony Liguori wrote: >> From: Anthony Liguori <aliguori at amazon.com> >> >> If MSI-X initialization fails after setting msix_enabled = 1, then >> the device is left in an inconsistent state. This would normally >>

Hi Michael, On Mon, Sep 15, 2014 at 1:32 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sun, Sep 14, 2014 at 08:23:26PM -0700, Anthony Liguori wrote: >> From: Anthony Liguori <aliguori at amazon.com> >> >> If MSI-X initialization fails after setting msix_enabled = 1, then >> the device is left in an inconsistent state. This would normally >>

The virtio modules do not advertise themselves as GPL but rely on exported GPL symbols. This makes them unloadable as modules. This patch adds the appropriate MODULE_LICENSE(). Signed-off: Anthony Liguori <aliguori@us.ibm.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 54a8017..8f6040d 100644 --- a/drivers/block/virtio_blk.c +++

The virtio modules do not advertise themselves as GPL but rely on exported GPL symbols. This makes them unloadable as modules. This patch adds the appropriate MODULE_LICENSE(). Signed-off: Anthony Liguori <aliguori@us.ibm.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 54a8017..8f6040d 100644 --- a/drivers/block/virtio_blk.c +++

On Mon, Sep 15, 2014 at 07:24:33AM -0700, Anthony Liguori wrote: > Hi Michael, > > On Mon, Sep 15, 2014 at 1:20 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Sun, Sep 14, 2014 at 08:29:33PM -0700, Anthony Liguori wrote: > >> From: Anthony Liguori <aliguori at amazon.com> > >> > >> See https://issues.oasis-open.org/browse/VIRTIO-16

From: Matt Wilson <msw@amazon.com> Commit f62805f1 introduced a bug where lazy MMU mode isn''t exited if a m2p_add/remove_override call fails. Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Anthony

virtio 1.0 support for virtio-pci isn't ready yet. Therefore, this patchset doesn't make any functional changes. Instead, this simply refactors virtio-pci, splitting legacy device support code out to a separate file: virtio_pci_legacy.c For virtio 1.0, all that's left is to add virtio_pci_modern.c supporting get_features finalize_features get (config) set (config) get_status

virtio 1.0 support for virtio-pci isn't ready yet. Therefore, this patchset doesn't make any functional changes. Instead, this simply refactors virtio-pci, splitting legacy device support code out to a separate file: virtio_pci_legacy.c For virtio 1.0, all that's left is to add virtio_pci_modern.c supporting get_features finalize_features get (config) set (config) get_status

We should prefer `const struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // <smpl> @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const

We should prefer `const struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // <smpl> @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const

Qumranet let us use their PCI vendor ID, with device ids >= 0x1000. We can specify that we accept all of them in the device ID table, and then return -ENODEV in the probe routine. modprobe will load all the modules which match a given alias so we might be loaded when we're not needed, but that's the worst that can happen. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

Qumranet let us use their PCI vendor ID, with device ids >= 0x1000. We can specify that we accept all of them in the device ID table, and then return -ENODEV in the probe routine. modprobe will load all the modules which match a given alias so we might be loaded when we're not needed, but that's the worst that can happen. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

Michael S. Tsirkin <mst at redhat.com> wrote: > Move everything dealing with legacy devices out to virtio_pci_legacy.c. > Expose common code APIs in virtio_pci.h > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> This breaks virtio_pci because you deleted the licence from it. -- >8 -- Subject: virtio_pci: Restore module licence and other attributes When the

Michael S. Tsirkin <mst at redhat.com> wrote: > Move everything dealing with legacy devices out to virtio_pci_legacy.c. > Expose common code APIs in virtio_pci.h > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> This breaks virtio_pci because you deleted the licence from it. -- >8 -- Subject: virtio_pci: Restore module licence and other attributes When the

We sometimes need to map between the virtio device and the given pci device. One such use is OS installer that gets the boot pci device from BIOS and needs to find the relevant block device. Since it can't, installation fails. Supply softlinks between these to make it possible. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Gleb, could you please ack that this patch below