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 15:02:18 -0400 Message-ID: <558072BA.1020005@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> <55803F82.2050500@Gmail.com> <20150616161435.GD1813@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150616161435.GD1813@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 12:14, Wei Liu wrote: > On Tue, Jun 16, 2015 at 11:23:46AM -0400, Don Slutz wrote: > [...] >>>>>> 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. >> > > I'm a bit lost here. Aren't you trying to preserve the same nic > configuration for Windows for compatibility reason (even if it's > slower)? Why is PV network involved? How does this work? > Yes, but there are 2 parts here: 1) boot time 2) run time At boot time, windows wants devices to be where they were and to be emulated. At run time "newer" windows can switch to "Hyper-V enlightened I/O" which as I understand it is like xen-netfront. I.E. Windows will start using xen-netback. Looking at http://www.techworld.com.au/article/303867/xen_3_4_0_released_more_client_device_hyper-v_integration/ It says "Also new is support for Microsoft's Hyper-V Enlightened I/O interface." And https://msdn.microsoft.com/en-us/library/cc768521%28v=bts.10%29.aspx says: "Presently, both Windows Server 2008 and Windows Vista support Hyper-V enlightened I/O and a hypervisor aware kernel via installation of Hyper-V integration services. Integration components, which include VSC drivers, are also available for other client operating systems." Also last I knew Citrix does provide Windows drivers that (also?) provided this faster access. This may require additional configuration and/or software to be installed on the windows disk. I did not see a clear reason to prevent Windows from using the faster access. -Don Slutz > Wei. > >> -Don Slutz >> >>> Wei. >>>