[libvirt] [PATCH v5] bhyve: implement PCI address allocation

[Ján Tomko]

On 05/26/2014 06:24 PM, Roman Bogorodskiy wrote:
>   Ján Tomko wrote:
> 
>> On 05/17/2014 07:49 PM, Roman Bogorodskiy wrote:
>>> Automatically allocate PCI addresses for devices instead
>>> of hardcoding them in the driver code. The current
>>> allocation schema is to dedicate an entire slot for each devices.
>>>
>>> Also, allow having arbitrary number of devices.
>>> ---
>>>  po/POTFILES.in                                     |   1 +
>>>  src/Makefile.am                                    |   4 +
>>>  src/bhyve/bhyve_command.c                          | 112 +++++++------
>>>  src/bhyve/bhyve_device.c                           | 174 +++++++++++++++++++++
>>>  src/bhyve/bhyve_device.h                           |  38 +++++
>>>  src/bhyve/bhyve_domain.c                           |  75 +++++++++
>>>  src/bhyve/bhyve_domain.h                           |  39 +++++
>>>  src/bhyve/bhyve_driver.c                           |  12 +-
>>>  .../bhyvexml2argvdata/bhyvexml2argv-acpiapic.args  |   2 +-
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-acpiapic.xml |   2 +
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-base.args    |   2 +-
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-base.xml     |   2 +
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-console.args |   4 +-
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-console.xml  |   2 +
>>>  .../bhyvexml2argv-disk-virtio.args                 |   2 +-
>>>  .../bhyvexml2argv-disk-virtio.xml                  |   2 +
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-macaddr.args |   2 +-
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-macaddr.xml  |   2 +
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-serial.args  |   4 +-
>>>  tests/bhyvexml2argvdata/bhyvexml2argv-serial.xml   |   2 +
>>>  20 files changed, 416 insertions(+), 67 deletions(-)
>>>  create mode 100644 src/bhyve/bhyve_device.c
>>>  create mode 100644 src/bhyve/bhyve_device.h
>>>  create mode 100644 src/bhyve/bhyve_domain.c
>>>  create mode 100644 src/bhyve/bhyve_domain.h
>>>
>>
>> ACK
> 
> Thanks!
> 
> One more thing that bothers me: after this change user needs to
> re-define a domain, otherwise domain will have no addresses and will
> fail to start.
> 
> Could/should it be handled somehow?

Yes, it would be nice not to break upgrades :)
In QEMU driver, this is done by calling AssignAddresses from QemuProcessStart.

> 
>>> --- a/src/bhyve/bhyve_command.c
>>> +++ b/src/bhyve/bhyve_command.c
>>> @@ -39,58 +39,48 @@
>>>  VIR_LOG_INIT("bhyve.bhyve_command");
>>>  
>>>  static int
>>> -bhyveBuildNetArgStr(const virDomainDef *def, virCommandPtr cmd, bool dryRun)
>>> +bhyveBuildNetArgStr(const virDomainDef *def,
>>> +                    virDomainNetDefPtr net,
>>> +                    virCommandPtr cmd,
>>> +                    bool dryRun)
>>>  {
>>
>>> +    char *brname = NULL;
>>> +    int actualType = virDomainNetGetActualType(net);
>>>  
>>> -    if (def->nnets != 1) {
>>> -        virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>>> -                       _("domain should have one and only one net defined"));
>>
>> I don't see this check re-added anywhere. Is it okay to have a domain with no
>> net now?
> 
> Interesting question. Initially, I've added this requirement because it
> was the only (easy) way to get into the guest. Now, as we have serial
> console support in bhyve, it's possible to get into domain without
> having any network interfaces, so user has a choice.
> 
> However, user could still not add serial console and network interface
> and end up with a unaccessible domain. Does it make sense from the user
> experience point of view to prevent this situation from happening?
> 

If bhyve is able to run the inaccessible domain, I think we should allow it.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140527/29aa880d/attachment-0001.sig>