On Thu, Dec 05, 2013 at 10:07:40AM +0000, Daniel P. Berrange wrote:
> On Thu, Dec 05, 2013 at 10:41:13AM +0800, Hu Tao wrote:
> > On Wed, Dec 04, 2013 at 03:53:17PM +0000, Daniel P. Berrange wrote:
> > > On Wed, Dec 04, 2013 at 08:46:53AM -0700, Eric Blake wrote:
> > > > On 12/04/2013 08:42 AM, Daniel P. Berrange wrote:
> > > > >> Dan, do you have any thoughts on the best representation to use? Or is
> > > > >> Hu's original proposal of:
> > > > >>
> > > > >> <pvpanic ioport='0x505'/>
> > > > >
> > > > > I'm not a fan of doing a special case attribute for 'ioport' - this is
> > > > > something something that should be part of an <address> element, since
> > > > > ioport numbers are a generic addressing concept for many devices.
> > > > > eg ISA serial / parallel ports have IRQ / IO ports IIUC.
> > > >
> > > > So something more like:
> > > >
> > > > <pvpanic>
> > > > <address type='ioport' slot='0x505'/>
> > > > </pvpanic>
> > > >
> > > > and introducing a new type='ioport' namespace into the <address> XML
> > > > since it is yet another numbering system for guest-visible addressing?
> > >
> > > Yes, I'm not sure I'd call the type 'ioport' - the address type reflects
> > > the bus/controller type that the device is associated with. What is the
> > > "bus" type that a pvpanic device is attached to ? Is it a ISA bus device,
> > > or is it a "platform" device or something else ? eg it might be appropriate
> > > to use
> > >
> > > <address type='platform' ioport='0x666'/>
> >
> > It's an ISA device. So the address should be:
> >
> > <address type='isa' ioport='0x505'/>
>
> Ok. It looks like it does not require an IRQ line though IIUC. For the
> general ISA address type though, we want to represent both ioport and
> IRQ values. So I guess we need the IRQ attribute to be optional in some
> manner.
Just to confirm it, so the general ISA address looks like:
<address type='isa' ioport='0xaaa' irq='123'/>
?
I checked attributes of several qemu ISA devices, iobase and irq are common,
but some device(isa-ide) has iobase2. Should we handle it as well?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list