Re: [PATCH 3/4] Allow vif= to specify PCI address for each nic

[Don Slutz <don.slutz@gmail.com>]

On 06/15/15 11:54, Wei Liu wrote:
> On Mon, Jun 15, 2015 at 10:15:51AM -0400, Don Slutz wrote:
>> This allows more then 32 nics.
>>
> 
> How does this patch help? What prevents you from having more than 32
> nics?
> 

Without a way to put the emulated nics onto a PCI to PCI Bridge, you are
limited to 1 PCI bus (the host one).

A PCI bus has a max of 32 PCI devices.

So, since the host bus has some PCI devices that are not nics, the limit
is smaller then 32.


>> This can help with Windows finding nics at boot time.
>>
>> This allows changing config file:
>>
>>     builder = "hvm"
>>     device_model_args_hvm = [
>>      "-device",
>>      "pci-bridge,chassis_nr=2,msi=on,id=pciBridge5.0,multifunction=on,addr=0x15.0",
>>      "-device",
>>      "vmxnet3,id=nic3,netdev=net3,mac=00:0c:29:86:44:be,bus=pciBridge5.0,addr=0x4.0x0",
>>      "-netdev",
>>      "type=tap,id=net3,ifname=vif.3-emu,script=/etc/qemu-ifup,downscript=no",
>>     ]
>>     vif = [
>>     ]
>>
>> to:
>>
>>     builder = "hvm"
>>     device_model_args_hvm = [
>>      "-device",
>>      "pci-bridge,chassis_nr=2,msi=on,id=pciBridge5.0,multifunction=on,addr=0x15.0",
>>     ]
>>     vif = [
>>      "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0,bus=pciBridge5.0,addr=0x4.0x0",
>>     ]
>>
>> which enables usage of xen-netback.
>>
> 
> In any case, exposing HVM-only options to top-level vif configuration
> space doesn't look right.


There are already HVM-only options in vifs:

### type

This keyword is valid for HVM guests only.
...
### model

This keyword is valid for HVM guest devices with `type=ioemu` only.
...

> Why do you want to set bus and addr? The
> rationale should be stated in commit message.


That is why I said:

>> This can help with Windows finding nics at boot time.

Windows boot code is not as flexible as Linux.  Most versions of Windows
like to blue screen if the hardware changes enough.

nics as not as important as disks, but some Windows configurations wants
to do network access during boot.  If you are lucky they do not blue
screen if the nic moves.

> 
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> CC: Don Slutz <dslutz@verizon.com>
>> ---
>>  docs/misc/xl-network-configuration.markdown | 14 ++++++++++++++
>>  tools/libxl/libxl_dm.c                      | 23 ++++++++++++++++++++---
>>  tools/libxl/libxl_types.idl                 |  2 ++
>>  tools/libxl/xl_cmdimpl.c                    |  4 ++++
>>  4 files changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/misc/xl-network-configuration.markdown b/docs/misc/xl-network-configuration.markdown
>> index 3c439d4..6a7f6db 100644
>> --- a/docs/misc/xl-network-configuration.markdown
>> +++ b/docs/misc/xl-network-configuration.markdown
>> @@ -60,6 +60,20 @@ strategy. Otherwise in general you should prefer to generate a random
>>  MAC and set the locally administered bit since this allows for more
>>  bits of randomness than using the Xen OUI.
>>  
>> +### bus
>> +
>> +Specifies the name of the network bridge which this VIF should be
>> +added to. The default is `xenbr0`. The bridge must be configured using
>> +your distribution's network configuration tools. See the [wiki][net]
>> +for guidance and examples.
>> +
>> +### addr
>> +
>> +Specifies the name of the network bridge which this VIF should be
>> +added to. The default is `xenbr0`. The bridge must be configured using
>> +your distribution's network configuration tools. See the [wiki][net]
>> +for guidance and examples.
>> +
> 
> The above two paragraphs don't make sense to me. Is that copy-n-paste
> error?
> 

Sigh, yes.  Will fix.

   -Don Slutz

> Wei.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>