From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH 3/4] Allow vif= to specify PCI address for each nic Date: Tue, 16 Jun 2015 11:23:46 -0400 Message-ID: <55803F82.2050500@Gmail.com> References: <1434377752-15705-1-git-send-email-dslutz@verizon.com> <1434377752-15705-4-git-send-email-dslutz@verizon.com> <20150615155445.GE10177@zion.uk.xensource.com> <557F0F36.6050202@Gmail.com> <20150616103259.GA22554@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150616103259.GA22554@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Keir Fraser , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Don Slutz , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 06/16/15 06:32, Wei Liu wrote: > On Mon, Jun 15, 2015 at 01:45:26PM -0400, Don Slutz wrote: >> 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. >> > > Is there anything that you can't accomplish by using > device_model_args_hvm? > Yes, you cannot use xen-netfront/xen-netback (PV access). >> >>>> 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", >>>> ] >>>> > > The way that you construct PCI bridge via device_model_args_hvm while > plumbing some other information via vif= is fragile and not general > useful to others. I don't think I would accept a half-baked solution > like this. > Ok. Will look to adding a pcibridge also. >>>> 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. >> > > Looks like you're trying to migrate a guest from VMWare to Xen. If > device_model_args_new is sufficient please just use that. > It works, but slowly because you are prevented from using the faster PV nics. -Don Slutz > Wei. >