[libvirt] [PATCH v2 1/2] Add pcihole64 attribute to root PCI controllers

Daniel P. Berrange berrange at redhat.com
Tue Aug 13 10:34:16 UTC 2013


On Tue, Aug 13, 2013 at 12:24:51PM +0200, Ján Tomko wrote:
> On 08/13/2013 11:54 AM, Daniel P. Berrange wrote:
> > On Tue, Aug 13, 2013 at 11:53:42AM +0200, Ján Tomko wrote:
> >> On 08/13/2013 10:55 AM, Daniel P. Berrange wrote:
> >>> On Tue, Aug 13, 2013 at 10:51:04AM +0200, Ján Tomko wrote:
> >>>> <controller type='pci' index='0' model='pci-root' pcihole64='1'/>
> >>>>
> >>>> It can be used to adjust (or disable) the size of the 64-bit
> >>>> PCI hole. The size attribute is in gigabytes, since it would
> >>>> get rounded up to nearest GB by QEMU anyway.
> >>>
> >>> Choosing the units based on what one specific hypervisor happens to
> >>> currently do has proven to be a pretty bad idea in the past. I'd say
> >>> we should be using KB here. Or better yet, have this as a separate
> >>> child element, and then support a 'units' attribute at the same time,
> >>> defaulting to KB. 
> >>>
> >>
> >> Would it be okay to use the largest usable unit when formatting the XML
> >> to make it more human-friendly?
> > 
> > No, because you'd be throwing away data if the user had requested less
> > than a GB. Outputting XML should use the smallest unit for which we
> > want to support, which IMHO should be KB.
> > 
> 
> By 'usable' I meant the unit that is the largest divisor of the size, e.g.:
> 512 KB would stay 512 KB, but 2048 MB would get translated to 2 GB.

Ewww, no. The output unit should always be the same for any given attribute.

> But this requires the applications parsing the XML to read both the size and
> the units.

Yep, this exactly why this is a bad idea


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 :|




More information about the libvir-list mailing list