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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jun 16, 2015 at 03:02:18PM -0400, Don Slutz wrote:
> 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.
> 

This makes sense. And it's what I understood what this patch was about.

> 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."
> 

Neither article mentioned Xen network driver. I doubt Hyper-V
Enlightened I/O has anything to do with Xen netback.

> 
> Also last I knew Citrix does provide Windows drivers that (also?)
> provided this faster access.
> 

Yes, that's true. I'm not sure it uses the same technique though.

In Linux, netfront writes to a magic IO port to unplug the emulated nic
and switch to using PV path. Does Citrix PV driver also uses the same
trick? Or does it take control from the beginning (i.e. no emulated nic
needed)?

If the answer is "no", that means you need to re-configure the guest
anyway, device_model_args_new should be enough to handle that one time
configuration for migration. If the answer is "yes", see below ...

> 
> 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.
> 

There's nothing in toolstack that prevents you from doing that. This
reasoning ("enable Windows to use faster path") is irrelevant to this
patch.

The problem is that you need more nics than we can possibly provide,
hence you need to introduce new interface to do that.

So the merit for accepting this patch is only whether the new interfaces
and options are sensible and general useful to others.

Wei.

>    -Don Slutz
> 
> 
> 
> > Wei.
> > 
> >>    -Don Slutz
> >>
> >>> Wei.
> >>>

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