[Pkg-xen-devel] Bug#922033: Bug#922033: xen: driver domain does not work

[Hans van Kranenburg]

On 2/16/19 1:41 PM, Hans van Kranenburg wrote:
> On 2/16/19 4:26 AM, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
>>> Creating new binary packages etc... is not an option anymore during the
>>> Buster freeze.
>>
>> Ok, I can carry myself a startup script calling actual xl directly. But
>> one thing would be very useful to have in buster - avoid starting
>> dom0 related services in guest. Otherwise even package installation
>> fails (if you happen to have the same version of xen packages in dom0
>> and domU). Would the below patch be acceptable?
> 
> That's a good one yes. There's some optimization of checks already been
> done in branch wip.testme [1], e.g. [2], but those checks would indeed
> still not result in a noop in a domU. Nice find!
> 
> I'll add your change later today, and resend it for review. I think the
> warning is not necessary, since a warning points at something that you
> should fix. This should just noop.

Actually, while looking at this again...

In the init script, we already have...

capability_check()
{
        [ -e "/proc/xen/capabilities" ] || return 1
        grep -q "control_d" /proc/xen/capabilities || return 1
        return 0
}

...which gets called like this...

        capability_check
        case "$?" in
                0) ;;
                *) log_end_msg 255; exit ;;
        esac

Looking at /proc/xen/capabilities and seeing if there's control_d inside
seems to be a more common way to check if this is a dom0.

It does log_end_msg 255 and 255 seems to be warning.

The upstream init script has...

# run this script only in dom0:
# no capabilities file in xenlinux domU kernel
# empty capabilities file in pv_ops domU kernel
if test -f /proc/xen/capabilities && \
   ! grep -q "control_d" /proc/xen/capabilities ; then
        exit 0
fi

...which also doesn't look really good, since this exit 0 doesn't happen
when /proc/xen/capabilities does *not* exist, and the first domU I'm
looking inside here doesn't have it.

Can you show what happens exactly when 'package installation fails'?

> In domU:
> -# cat /sys/hypervisor/uuid
> d5ad9b8c-b230-4bba-a74d-04049d090a36
> 
> In dom0:
> -# cat /sys/hypervisor/uuid
> 00000000-0000-0000-0000-000000000000
> 
> Thanks,
> Hans
> 
> [1] https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
> [2]
> https://salsa.debian.org/xen-team/debian-xen/commit/30c9a3c54332f34c515143b261514a04e1e1d13c
> 
>> -----8<-----
>>
>> From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
>>  <marmarek at invisiblethingslab.com>
>> Subject: [PATCH] Do not start dom0 services if running inside domU
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com>
>> ---
>>  debian/xen-utils-common.xen.init | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
>> index 4b793d5ac2..d73e827514 100644
>> --- a/debian/xen-utils-common.xen.init
>> +++ b/debian/xen-utils-common.xen.init
>> @@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
>>  	exit 0
>>  fi
>>  
>> +if grep -q '[^0-]' /sys/hypervisor/uuid; then
>> +	log_warning_msg "Xen guest detected"
>> +	exit 0
>> +fi
>> +
>>  XENCONSOLED="$ROOT"/bin/xenconsoled
>>  XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
>>  XENSTORED="$ROOT"/bin/xenstored
>>
>