Re: Guests networking using driver domain

[Felix Kuperjans <felix@xxxxxxxxxxxxxxxxxx>]

Am 07.03.22 um 11:27 schrieb Andrea Stevanato:
> On 3/3/22 23:37, Felix Kuperjans wrote:
> > Hi Andrea,
> >
> > I think this might be related to problems with the VIF hotplugging on 
> > "guest0".
> > Since the vifX.0 on guest0 is successfully created, some of the 
> > hotplugging at least works, but maybe a failure to setup it correctly 
> > leads to the problem in "guest1".
> >
> > A few questions for further investigation:
> >
> > Is the vifX.0 device up and having "master xenbr0" (see ip link show)?
> The vifX.0 do not have "master xenbr0".
>
> > If not, there is definitely a problem with the bridge hotplugging.
> >
> > Which daemon handles the vif hotplugging? xl devd? is 
> > /etc/xen/xl.conf configured correctly (usually having 
> > vif.default.script="vif-bridge" and run_hotplug_scripts=1)?
> The configuration file is all commented, actually also in dom0 it is the
> same.
>
> > Do the hotplugging scripts exist, esp. /etc/xen/scripts/vif-bridge ? 
> > Can you see any log messages from this script in 
> > /var/log/xen/xen-hotplug.log?
> Yes, the vif-bridge script exists. No, the /var/log/xen directory is 
> empty.
> > Usually I would expect one of these to have a notable error causing 
> > the script to not be called or not run properly.
> > Otherwise, some more log output from guest0 would be helpful, dmesg, 
> > log messages about the hotplugging, ...
> Please have a look at 
> https://lore.kernel.org/xen-devel/1d00a228-a699-5743-69ae-4dbadee5ebb9@xxxxxxxxxxxxxxx/T/#m50eed0b51f2fc8b0ac26bc269dd5119f83041dd0 
> where I posted the full
> log of xl -vvv devd -F executed on guest0.
>
> > Best Regards
> > Felix
> Cheers,
> Andrea

Hi Andrea,

Thank you for your message and pointing to the Xen devel communication. 
I've also been reading the thread on Xen Devel already out of curiosity.
I was actually surprised that your distribution (petalinux) seems to 
include a very restrictive XSM by default - normally I would consider 
XSM something you only enable if you know what you're doing and you know 
exactly how your use case looks like.
Seems like you got it working by switching to a default XSM 
configuration. I think petalinux should include a warning to its users 
that many Xen functions will be prevented by them changing the default 
to the very restricted SILO mode (like e.g. all backend/driver domains).
If you want to, I think you could develop a proper XSM configuration for 
this setup, which only allows the "guest0" to act as a network backend 
domain and use it - but this requires setting it up in the policy 
properly additionally to the configuration in the domain's configuration 
file.
Cheers
Felix