On Tue, May 22, 2018 at 08:48:58AM -0500, Venu Busireddy wrote:
> On 2018-05-22 11:03:37 +0100, Stefan Hajnoczi wrote:
> > On Fri, May 18, 2018 at 04:43:36PM -0500, Venu Busireddy wrote:
> > > On 2018-05-18 17:06:23 +0100, Stefan Hajnoczi wrote:
> > > > On Thu, May 17, 2018 at 09:06:04AM -0400,
On 2018-05-22 11:03:37 +0100, Stefan Hajnoczi wrote:
> On Fri, May 18, 2018 at 04:43:36PM -0500, Venu Busireddy wrote:
> > On 2018-05-18 17:06:23 +0100, Stefan Hajnoczi wrote:
> > > On Thu, May 17, 2018 at 09:06:04AM -0400, Venu Busireddy wrote:
> > >
> > > Can you describe a use case where
On Fri, May 18, 2018 at 04:43:36PM -0500, Venu Busireddy wrote:
> On 2018-05-18 17:06:23 +0100, Stefan Hajnoczi wrote:
> > On Thu, May 17, 2018 at 09:06:04AM -0400, Venu Busireddy wrote:
> >
> > Can you describe a use case where vendor-specific extensions make sense
> > as opposed to extending
On 2018-05-18 17:06:23 +0100, Stefan Hajnoczi wrote:
> On Thu, May 17, 2018 at 09:06:04AM -0400, Venu Busireddy wrote:
>
> Can you describe a use case where vendor-specific extensions make sense
> as opposed to extending the VIRTIO specification?
Sometimes, qemu may need to group certain devices
On Thu, May 17, 2018 at 09:06:04AM -0400, Venu Busireddy wrote:
Can you describe a use case where vendor-specific extensions make sense
as opposed to extending the VIRTIO specification?
This proposal only supports the PCI transport, so do extensions only
affect the PCI transport behavior or also
Add VIRTIO_PCI_CAP_VENDOR_EXT_CFG to the virtio PCI capabilities to
allow vendors to define vendor specific extension.
Signed-off-by: Venu Busireddy
---
content.tex | 43 +++
1 file changed, 43 insertions(+)
diff --git