All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>
Cc: libvir-list@redhat.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [libvirt] [PATCH 3/9] Add new domain device: "controller"
Date: Thu, 24 Sep 2009 11:52:14 +0100	[thread overview]
Message-ID: <20090924105214.GC21831@redhat.com> (raw)
In-Reply-To: <1253287576-12875-4-git-send-email-wolfgang.mauerer@siemens.com>

On Fri, Sep 18, 2009 at 05:26:10PM +0200, Wolfgang Mauerer wrote:
> This augments virDomainDevice with a <controller> element
> that is used to represent disk controllers (e.g., scsi
> controllers). The XML format is given by
> 
> <controller type="scsi" id="<my_id>">
>    <bus addr="<Domain>:<Bus>:<Slot>">
> </controller>
> 
> where type denotes the disk interface (scsi, ide,...), id
> is an arbitrary string that identifies the controller for
> disk hotadd/remove, and bus addr denotes the controller address
> on the PCI bus.
> 
> The bus element can be omitted; in this case,
> an address will be assigned automatically. Currently,
> only hotplugging scsi controllers on a PCI bus
> is supported, and this only for qemu guests

As mentioned in the previous patch, I reckon 'id' is better
called 'name'. 

For PCI addresses, it is desirable to fully normalize the XML
format, by which I mean have separate attributes for domain,
bus and slot. We already have a syntax for PCI addresses used
for host device passthrough, so it'd make sense to use the
same syntax here for controllers. More broadly, we're probably
going to have to add a PCI address element to all our devices.
While it is unlikely we'll need non-PCI addresses, it doesn't
hurt to make it explicit by adding a type='pci' attribute

Thus I'd suggest

    <address type='pci' domain='0x0000' bus='0x06' slot='0x12'/>

Instead of

    <bus addr="<Domain>:<Bus>:<Slot>">

In the domain_conf.c/.h parser, we could have a datatype like

   enum {
      VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI,

      VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST
   };

   typedef struct _virDomainDevicePCIAddress virDomainDevicePCIAddress;
   struct _virDomainDevicePCIAddress {
        unsigned domain;
        unsigned bus;
        unsigned slot;
        unsigned function;
   };
   typedef struct _virDomainDeviceAddress virDomainDeviceAddress;
   struct _virDomainDeviceAddress {
      int type;
      union {
         virDomainDevicePCIAddress pci;
      } data;
   };


Which we then use in all the places in domain_conf.h wanting
address information. Obviously we'd not use the 'function'
field in most places, but doesn't hurt to have it.

And a pair of methods for parsing/formatting this address info
we can call from all the appropriate locations.


> diff --git a/src/domain_conf.h b/src/domain_conf.h
> index 898f6c9..6b3cb09 100644
> --- a/src/domain_conf.h
> +++ b/src/domain_conf.h
> @@ -111,6 +111,11 @@ struct _virDomainDiskDef {
>      char *src;
>      char *dst;
>      char *controller_id;
> +    struct {
> +        unsigned domain;
> +        unsigned bus;
> +        unsigned slot;
> +    } controller_pci_addr;

I think we should stick to just using the controller name
as the mandatory identifier for cross-referencing disks
to controllers.

>      char *driverName;
>      char *driverType;
>      char *serial;
> @@ -125,6 +130,19 @@ struct _virDomainDiskDef {
>      virStorageEncryptionPtr encryption;
>  };
>  
> +/* Stores the virtual disk controller configuration */
> +typedef struct _virDomainControllerDef virDomainControllerDef;
> +typedef virDomainControllerDef *virDomainControllerDefPtr;
> +struct _virDomainControllerDef {
> +    int type;
> +    char *id;
> +    struct {
> +        unsigned domain;
> +        unsigned bus;
> +        unsigned slot;
> +    } pci_addr;
> +};

With the generic address data type and s/id/name/, this would be just

  struct _virDomainControllerDef {
     int type;
     char *name;
     virDomainDeviceAddress addr;
  };


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2009-09-24 10:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 15:26 [Qemu-devel] [PATCH 0/9] Support disk-hotremove and controller hotplugging Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 1/9] Clarify documentation for private symbols Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 2/9] Extend <disk> element with controller information Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 3/9] Add new domain device: "controller" Wolfgang Mauerer
2009-09-24 10:52   ` Daniel P. Berrange [this message]
2009-09-18 15:26 ` [Qemu-devel] [PATCH 4/9] Add disk-based hotplugging for the qemu backend Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 5/9] Implement controller hotplugging Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 6/9] Allow controller selection by ID Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 7/9] Remove surprises in the semantics of disk-hotadd Wolfgang Mauerer
2009-09-24 10:59   ` [Qemu-devel] Re: [libvirt] " Daniel P. Berrange
2009-09-18 15:26 ` [Qemu-devel] [PATCH 8/9] Factor out the method to get the PCI address of a controller for a given disk Wolfgang Mauerer
2009-09-18 15:26 ` [Qemu-devel] [PATCH 9/9] Implement disk- and controller hotremove Wolfgang Mauerer
     [not found] ` <20091009163203.GA30218@redhat.com>
2009-10-13  9:08   ` [Qemu-devel] Re: [libvirt] [PATCH 0/9] Support disk-hotremove and controller hotplugging Gerd Hoffmann
2009-10-13  9:34     ` Wolfgang Mauerer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090924105214.GC21831@redhat.com \
    --to=berrange@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wolfgang.mauerer@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.