Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 02.12.2011 11:41, Pasi Kärkkäinen wrote:
> On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote:
>> On 01.12.2011 19:09, Pasi Kärkkäinen wrote:
>>> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
>>>> Moving to public discussion...
>>>>
>>>> This was found with Xen hypervisor version supporting device unplugging 
>>>> and the
>>>> domU kernel having net-/blkfront and pci platform built-in (or as module).
>>>>
>>>> The block device is defined as hda and the NIC type=ioemu (so theoretically
>>>> guests without pv support would work, too).
>>>>
>>>> Since both drivers are present, the kernel tries to unplug the emulated 
>>>> devices
>>>> and succeeds. The blkfront driver detects the xvda device available in 
>>>> parallel
>>>> and is working ok.
>>>>
>>>> However the network interface does not work. There are entries present 
>>>> under
>>>> sysfs for the xenbus but trying to bring it up fails with errors. And also 
>>>> there
>>>> seems to be no mac address set (all zeros in sysfs).
>>>> When the type=ioemu is removed in the configuration, this works.
>>>>
>>>> I have not much more debugging information beyond that, yet. But it sounds 
>>>> a bit
>>>> like NICs should behave the same as block devices. So if there is an 
>>>> emulated
>>>> device defined there will be an alternate paravirt interface for it and 
>>>> after
>>>> unplugging the emulated ones we end up with the pv ones.
>>>> Is that something that can be seen with newer Xen versions, too (I am 
>>>> using 4.1.1)?
>>>>
>>>
>>> Hey,
>>>
>>> Have you seen?: 
>>> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
>>>
>>> Especially the following note:
>>> "NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM drivers 
>>> WILL NOT work! Don't specify "type" parameter for the vif. (with type=ioemu 
>>> the pvhvm nic in the VM will have mac address full of zeroes - and thus 
>>> won't work!)."
>>>
>>> "type=ioemu" is not needed, at least with xm/xend toolstack both HVM and 
>>> PVHVM guests work OK without it.
>>>
>>> -- Pasi
>>>
>> Thanks Pasi,
>>
>> hmm, so it is documented actually and thus sort of expected. Still it is
>> confusing. For one driver it does not make a difference to use the form of an
>> emulated device in the config, for the other it does. The xl stack works, 
>> the xm
>> stack does not.
>> And then, ok this is probably a quite naive approach, it seemed to make 
>> sense to
>> go through the pain of always having potentially both interfaces available
>> (emulated and pv) so in theory the same guest config can accommodate a guest 
>> os
>> supporting one or the other (or easily switch from one to the other). 
>> Otherwise
>> I would expect an emulated device only when I have hd? in the config and a pv
>> device when I write xvd?.
>>
> 
> This works for both HVM and PVHVM (also mentioned on the wiki page):
> vif = [ 'mac=00:16:5e:02:07:45, bridge=xenbr0, model=e1000' ]
> 
> So there's no need for "type=ioemu" option with xm/xend.
> 
> You can switch between HVM and PVHVM with:
> xen_platform_pci=0|1
> 
> -- Pasi
> 

It seems that this works (without the model, too) for xm and xl. So even without
explicitly saying type=ioemu, there is an emulated device created. And if the
platform device is enabled, the emulated devices are unplugged by default.
So it sounds like "type=ioemu" is not only not needed but hurts in the one case
of xm. Would it make sense to completely remove it from the example configs?

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel