[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration |
Date: |
Tue, 20 Sep 2016 17:44:45 +0100 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Tue, Sep 20, 2016 at 10:12:20PM +0530, Kirti Wankhede wrote:
>
>
> On 9/20/2016 10:06 PM, Daniel P. Berrange wrote:
> > On Tue, Sep 20, 2016 at 10:01:18PM +0530, Kirti Wankhede wrote:
> >>
> >>
> >> On 9/20/2016 8:44 PM, Daniel P. Berrange wrote:
> >>> On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> >>>>
> >>>>
> >>>> On 20/09/2016 16:58, Daniel P. Berrange wrote:
> >>>>>>> As I've said in my earlier reply - libvirt will *NOT* support passing
> >>>>>>> arbitrary vendor specific parameters as a blob via the XML. Everything
> >>>>>>> that appears in the XML must be *fully* specified and explicitly
> >>>>>>> represented in the XML as a distinct attribute or element.
> >>>>>>
> >>>>>> Are generic key/value attributes (e.g. a <attribute> element)
> >>>>>> acceptable?
> >>>>>
> >>>>> Only if libvirt has a known list of valid attribute key names upfront.
> >>>>> We don't want to just blindly expose arbitary vendor specific keys
> >>>>> exposed
> >>>>> by the kernel. Libvirt's job is to ensure the XML representation is
> >>>>> vendor
> >>>>> portable
> >>>>
> >>
> >> In key/value attributes (taking example from proposed xml file)
> >>
> >> <attribute name='resolution'>2560x1600</attribute>
> >>
> >> 'Key' (i.e. 'resolution') should be known upfront, not the value, right?
> >
> > Yes, the actual value is not important - only its structured.
> > ie, libvirt would check that it is in the format '$WIDTHx$HEIGHT'
> > and reject it if not.
> >
>
> In this particular example, libvirt checks if its integer? or value
> could be 2560x1600 or 4096x4096 both are valid?
>
> Does libvirt accept string value?
Err, as I said, we'd validate that its in the format '$WIDTHx$HEIGHT'
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, (continued)
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/19
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Paolo Bonzini, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Paolo Bonzini, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration,
Daniel P. Berrange <=
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Paolo Bonzini, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/20
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/19
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/20