PVH patches for Xen 4.8

127 views
Skip to first unread message

Marek Marczykowski-Górecki

unread,
Jan 22, 2018, 3:17:48 PM1/22/18
to Simon Gaiser, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

The "8.4.3pre-shim-comet" branch on xenbits.xen.org/xen.git contains a
backport of PVH to Xen 4.8 (and comet shim as the top 3-4 patches). In
practice this is mostly about libxl changes (type="pvh" instead of
device_model_version="none"), but there are also few fixes for other
code, like ACPI tables builder. Those do fix some existing minor bugs.
For example wrongly advertised i8042 controller, causing ~1s delay on
Linux boot.

It seems like the type="pvh" is what Xen is going to support and
device_model_version="none" is abandoned in new versions. This means
that it may be harder to backport further PVH-related patches, and also
upstream our patches to Xen. There is not much changes on libxl side,
but still.
This also means that our libvirt patch in its current shape will be
rejected, and we'll need to maintain it separately.

Changing this that late in the release cycle may not be a good idea, but
changing it later, or having to maintain duplicated set of patches
and having additional difficulty with backporting other patches may also
be a pain.

Simon, can you take a look at this? What do you think about this? And if
you think it worth changing it now, please create appropriate pull
requests.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpmRqwACgkQ24/THMrX
1yyBHgf5AaaL1UdNm0+nNaqkHEQKhw1fr3X0/ZWToim8sMKn9943Azda0CkuXh3N
PKQDutC6bd998maLkBp1aJoXgWZd78jv51Z55nK/Kfudd+QPGCr0QSO5LnC28lAh
VGBGAK2Zj2q1h6SW72r8WZW3Xa7KAGbgZfabPbX10idDHNKly+x/LWU12XMmST0C
cHZX/FUeI1m1gawQe0mquBus6fnhJJ1ho8t9MshnlupQ1yyzMxlbDsJf5GBsmi8I
5qvxLgNTu9YzkxwnLsRON6Wra88cpJSgvKn9ljiU95T4yicHR+yf2s1Kv0/+mQ6U
9Tpn3lAhvwITaYi0RwEAcY6V++eiLg==
=63Xa
-----END PGP SIGNATURE-----

Simon Gaiser

unread,
Jan 23, 2018, 9:39:38 AM1/23/18
to Marek Marczykowski-Górecki, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:
> Hi,
>
> The "8.4.3pre-shim-comet" branch on xenbits.xen.org/xen.git contains a
> backport of PVH to Xen 4.8 (and comet shim as the top 3-4 patches). In
> practice this is mostly about libxl changes (type="pvh" instead of
> device_model_version="none"), but there are also few fixes for other
> code, like ACPI tables builder. Those do fix some existing minor bugs.
> For example wrongly advertised i8042 controller, causing ~1s delay on
> Linux boot.
>
> It seems like the type="pvh" is what Xen is going to support and
> device_model_version="none" is abandoned in new versions. This means
> that it may be harder to backport further PVH-related patches, and also
> upstream our patches to Xen. There is not much changes on libxl side,
> but still.
> This also means that our libvirt patch in its current shape will be
> rejected, and we'll need to maintain it separately.
>
> Changing this that late in the release cycle may not be a good idea, but
> changing it later, or having to maintain duplicated set of patches
> and having additional difficulty with backporting other patches may also
> be a pain.
>
> Simon, can you take a look at this? What do you think about this? And if
> you think it worth changing it now, please create appropriate pull
> requests.

I think the deciding factor is whether future 4.8.z releases will
include them (so that we can simply update instead of applying single
patches). But unfortunately this seems to be simply not decided yet [1].

If they change it, updating now would be much better because to install
the update libxenlight.so, libvirt and core-admin need to be
synchronized.

Since the mail reads like it's more likely that it will be backported and
AFAICS the change to type=pvh is rather small (so not so hard to
backport if it not ends in the official release) I lean towards
including the backports now. What do you think?

[1]: https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02004.html
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlpnSTAACgkQkO9xfO/x
ly9pdg//cP/oH5HiFaovpUnq4z0iiYwaVzT56VdTGkSbw45v9MqKfeAjg+kCA9Zw
ZqAm1l5XDGaJea81cxacdHRk6n/u51b0yVOVItE//m2RktUXcEjWEi4JxxwLufAJ
FK3Kh0rG2IvHBUsOBwnZSTIhzIjeVKj3NB582xdMzd/8ndCRRx+0xbnKablkO0V0
C5zAgbW8XNbIc0rmOyMBeYGI3YuFiH1wzzVCsWK2xYfNwtpyYjew1gOu+weYWH5M
t9o4Rgdlv4FNYKMvnXuStNBw7O8ChjHiGuYuEE6aN3fQ4sQCQO2vdAX4U4N8weop
by3kV94O1wA+gx+CCLZ83ZbTqtp+VqDoLEMvxI5oiYBVwhyL+rCrJaXTy5E+9T80
BgbY3Hg3rTPcPwzC8Vscx5ZUJ4/2UI+TnHFKSuRhN8vf6yPNPz3H9/859lE5Bss9
aNUbxuzDu8OgXQfALL593rmy7ANfVT7A3iMCUkxfVDCViKhW2yZwGoH1l6nNUfHI
VPcS36UDhGNml5k6pBSOC0QZFhmy8TvJCXrLbHOGk4drlG18JxHiUqPtFL8wNKis
93ijzSvfGYvd3WnB4SHX+JxjgN6FEqvGuhvIe0gZhh67y1T4WvC5Mk83Mbr1hADL
z/0j+WOol20/KcyZwoh513kNwPeUdqaCKiu5pvOBo7hsy25jXKg=
=RPIv
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Jan 23, 2018, 9:55:52 AM1/23/18
to Simon Gaiser, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yes, this is exactly why I bring this idea right now. Having
synchronized update is always a pain (in some corner cases may lead to
removing packages).

> Since the mail reads like it's more likely that it will be backported and
> AFAICS the change to type=pvh is rather small (so not so hard to
> backport if it not ends in the official release) I lean towards
> including the backports now. What do you think?

Well, change to type=pvh is not exactly small. It's 15-something patches
touching different libxl files... But it looks it wasn't that hard to
backport it from 4.10 (mostly differences because of libxl.c split),
generally the code structure is very similar.
So, I also lean towards including it now.

> [1]: https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02004.html

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpnTLYACgkQ24/THMrX
1ywaUwf/WtSwMtx2bpDPtgoCJ4HZfKGtiX6iLQ1MKFX4U+dJxzXi7qWlNoWqbqZK
/JdPK58GP7W3QcXsHfOUuuiow5dYtHYiFBlOIUVdJSnP3S2dO2q/aAkkmKmozkYB
Fr055jLWHQxXfwBmQMru4agxLi+We9dbXYx2aOBuAgeSnYIC4WqUPgLOJYdIfbbO
pR3dcBd8MSsyBV9qf2Q4HebTOF84UQfrFZBpHhz3P43dRkqLYSFAUDXvche4u0b3
sa3L92bkbI7sBRb1Hs4aT0NTvPSeCowJx6crhWtm5wOlZuKojRZziEkdKsuZ/cuJ
YZa1yX6bJiglXtGKPRtb+wdIG43R5g==
=pnuI
-----END PGP SIGNATURE-----

Simon Gaiser

unread,
Jan 23, 2018, 10:08:29 AM1/23/18
to Marek Marczykowski-Górecki, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:
Ah, yeah, you're right. I seem to have missed some "preparation" patches
when looking at it yesterday.

> So, I also lean towards including it now.

Ok. Then let's hope it will be included in future releases.
iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlpnT/UACgkQkO9xfO/x
ly+kpw/+JA8CWGccJ/SlCPGhJnM8G0YpT7fDBMYt/MdPyjH4noODS1m7TpI32v/E
K/C5vKulwsJO2fKiBYCmV+hECjlbTOS1OFkbnqt3+oVRORpuPoS7BDBS3uOhvODr
+XUBQGHe7X+uYUkuF4ER+pYx1VISjOmym9QWcqydzsZfApf6/uTNmjRKAqcNZU0q
0BqwjTL0r4D22jIk/lUVrlLpQiumqVn6Y9MRonwqvxRuBgchO8Q6G1FXqzGxTLP3
WR7olqE0irSJBsFXGDoyY8iV7DOSG5KKaqWxWqzMpsQpk0rxkXi+iLgJJaImwhb/
hzZ4Wlm/fAOB5ZR0Qc7pJjiQ/FcokfhCQBxmCAdazrxm3WsLazjlrDUdVjjePWyO
FxhxXC7bJkfEExkLZ0sCfJFDD8fXMN/kqtmIRkcZt9gdZqcB8H2CHg3j1sHWN01Y
Pm6uwI7hc5dAfiaWCIRG3VlQ85on29Oa5KvRrNV1UXfSVvbfI7U4nwBJWeKLjIgN
Pg5eJg2/OKz6VXW+2bIdH14z4gPqKAC55rF3kU1guqHHLzt693e244adXFcyYLVJ
cRO9MOL/y5cWynoqr1ct/tVXiv0nWTgSv99VChpSRptvfg5YwXlNTh4+vP2M4Srn
niJgbv5NHyP1zwgKccw2NDtxahGivtmgnDUmi0HgdziyJfV3uQI=
=UCXZ
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages