Update to Xen 4.7.0

[mar...@wetwa.re]

Hi,

this is just a heads-up about a preliminary work I've been doing to get Xen 4.7.0 working on Qubes 3.2 rc2 (mainly motivated to see if any of the massive amount of changes would have any effect on PCI/GPU passthrough).

VMM-XEN:
https://github.com/WetwareLabs/qubes-vmm-xen/tree/xen-4.7

Most changes are straightforward modifications of Qubes patches (surrounding lines in original files been changed and this causes patching to fail). Some patches required a little bit more tinkering And few changes were made to the build process.

Also Libvirt, libvchan and gui-daemon needed minor changes:

https://github.com/WetwareLabs/qubes-core-libvirt/tree/xen-4.7
https://github.com/WetwareLabs/qubes-core-vchan-xen
https://github.com/WetwareLabs/qubes-gui-daemon


With these modifications, it builds ok (in Fedora 23 AppVM on Qubes 3.1) and can be installed from ISO. However there's now something wrong with gui-daemon (I suspect):
VMs will start, but if any application (xterm for example) is started, the green dot on QubesManager changes to yellow, and no window is created. If another app is launched, then a window briefly flashes and closes again. Every time this happens, there's this log (in guid.sys-firewall.log for example):

ErrorHandler: BadValue (integer parameter out of range for operation)
Major opcode: 130 (MIT-SHM)
Minor opcode: 3 (X_ShmPutImage)
Value: 0x1f5
Failed serial number: 88
Current serial number: 89

But with qvm-run I can run commands properly in this VM.
I tried looking into gui-daemon code, but it seems this error is created somewhere else outside of gui-daemon (it's only catched by the daemon).

Also there this line in libxl-driver.log:

libxl:error: libxl.c:1840:libxl_console_tty: unable to read console tty path '/local/domain/4/console/tty': Function not implemented.

But this appears at some point during/after boot, and I don't know if it's related to this bug.

I didn't dare to make a pull request on GitHub, since this is currently in broken state. But if you're moving to use 4.7.0 at some point (maybe Qubes 4.0?),  feel free to use this to avoid duplicate work :)

Br,
Marcus

[Outback Dingo]

would you happen to have an iso i can test as I am one of the users that cannot use Qubes right now due to pci passthru issues for greater then 6+ months being unresolved.

 

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0f8acb48-7dd6-4b2c-bc59-768836c02b9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Aug 04, 2016 at 01:45:58PM -0700, mar...@wetwa.re wrote:
> Hi,
>
> this is just a heads-up about a preliminary work I've been doing to get Xen
> 4.7.0 working on Qubes 3.2 rc2 (mainly motivated to see if any of the
> massive amount of changes would have any effect on PCI/GPU passthrough).
>
> VMM-XEN:
> https://github.com/WetwareLabs/qubes-vmm-xen/tree/xen-4.7
>
> Most changes are straightforward modifications of Qubes patches
> (surrounding lines in original files been changed and this causes patching
> to fail). Some patches required a little bit more tinkering And few changes
> were made to the build process.

Thanks! It's too late to have it in R3.2, but we surely want Xen 4.7 in
Qubes 4.0.

> Also Libvirt, libvchan and gui-daemon needed minor changes:
>
> https://github.com/WetwareLabs/qubes-core-libvirt/tree/xen-4.7

Take a look at core3-devel branch on my github - there is already
libvirt 2.0.0.

> https://github.com/WetwareLabs/qubes-core-vchan-xen
> https://github.com/WetwareLabs/qubes-gui-daemon
>
>
> With these modifications, it builds ok (in Fedora 23 AppVM on Qubes 3.1)
> and can be installed from ISO. However there's now something wrong with
> gui-daemon (I suspect):
> VMs will start, but if any application (xterm for example) is started, the
> green dot on QubesManager changes to yellow, and no window is created. If
> another app is launched, then a window briefly flashes and closes again.
> Every time this happens, there's this log (in guid.sys-firewall.log for
> example):
> ErrorHandler: BadValue (integer parameter out of range for operation)
> Major opcode: 130 (MIT-SHM)
> Minor opcode: 3 (X_ShmPutImage)
> Value: 0x1f5
> Failed serial number: 88
> Current serial number: 89

Looks like your X server don't have shmoverride preloaded, or its
startup failed. Check stderr of X server - if started from lightdm, it
will be in /var/log/lightdm/x-0.log.

> But with qvm-run I can run commands properly in this VM.
> I tried looking into gui-daemon code, but it seems this error is created
> somewhere else outside of gui-daemon (it's only catched by the daemon).
>
> Also there this line in libxl-driver.log:
> libxl:error: libxl.c:1840:libxl_console_tty: unable to read console tty
> path '/local/domain/4/console/tty': Function not implemented.
>
> But this appears at some point during/after boot, and I don't know if it's
> related to this bug.

The same is on Xen 4.6, harmless.

> I didn't dare to make a pull request on GitHub, since this is currently in
> broken state. But if you're moving to use 4.7.0 at some point (maybe Qubes
> 4.0?), feel free to use this to avoid duplicate work :)

:)

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXo7pyAAoJENuP0xzK19csDMcH/10g+19GhEUDCOxuHa64Tg57
DgQePoZ6PGEVDODoeoL0yeKrbPqGfDFVs2qyoRx0Dy3fHwn40D8O3jtIRfW+FYb+
MuLV0+1YcY44KSjgl+anGwmyg5yEbQypuM7/d5WClFavOyx0EJxUxWE4lDyoDNxi
NVfK83DnhT2qGOElF3wi7FHsZ9cW0U9u7pAaAqLddw5yj8af+pZaSxkIVcoNTS34
6qa8loHcNICc/guzf+wvHEaGovsh5SZjWKtj03PL/Mpt/7QhmxSbrt2t6H4y4imv
mvdWJ0fttCPjseDSd+Jlkv4yKF2kDFOz/U6LWgtlmPFHFFafaazjfkmEx8p7mus=
=QYAU
-----END PGP SIGNATURE-----

[mar...@wetwa.re]

Marek, thanks for your advice!

I looked more into the shmoverride issue. There's this sequence of events that cause this:
- OS boots. Pass the login screen
- shmoverride is loaded ("shmoverride constructor running")
- X crashes in 1-2 seconds after login completes and desktop/QubesManager is shown.
This is in Xorg.0.log.old:

[  2285.229] (EE) Backtrace:
[  2285.229] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5978f9]
[  2285.230] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f8cd98b2aaf]
[  2285.230] (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0x1e7) [0x7f8cd99c6547]
[  2285.231] (EE) 3: /usr/lib64/xorg/modules/drivers/radeon_drv.so (_init+0x2b07f) [0x7f8cd35b9b9f]
[  2285.231] (EE) 4: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x57fd) [0x7f8cd22be9fd]
[  2285.231] (EE) 5: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x593f) [0x7f8cd22bf81f]
[  2285.231] (EE) 6: /usr/bin/X (miCopyRegion+0x1ab) [0x57341b]
[  2285.231] (EE) 7: /usr/bin/X (miDoCopy+0x466) [0x5739c6]
[  2285.232] (EE) 8: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x3ee5) [0x7f8cd22bc3b5]
[  2285.232] (EE) 9: /usr/bin/X (DamageRegionAppend+0x3551) [0x521611]
[  2285.232] (EE) 10: /usr/bin/X (SyncVerifyFence+0x1d8c) [0x4d3efc]
[  2285.232] (EE) 11: /usr/bin/X (SyncVerifyFence+0x36c5) [0x4d73e5]
[  2285.232] (EE) 12: /usr/bin/X (SendErrorToClient+0x2df) [0x436a3f]
[  2285.232] (EE) 13: /usr/bin/X (remove_fs_handlers+0x453) [0x43aa53]
[  2285.233] (EE) 14: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f8cd989e580]
[  2285.233] (EE) 15: /usr/bin/X (_start+0x29) [0x424d99]
[  2285.234] (EE) 16: ? (?+0x29) [0x29]
[  2285.234] (EE)
[  2285.234] (EE) Segmentation fault at address 0xffffffffcaa1d7b4
[  2285.234] (EE)
Fatal server error:
[  2285.234] (EE) Caught signal 11 (Segmentation fault). Server aborting

- X is restarted automatically. Back to login screen
- shmoverride.so is restarted but it fails because /var/run/shm.id exists already
- Now after login the X stays up and doesn't crash. but GUI operations on VMs cause the abovementioned BadValue-error described in first post.

I forced the shmoverride to overwrite shm.id so it is restarted correctly, but this causes X to crash and restart always when desktop is reached.

I first thought the crash would have something to do with radeon driver, but the trace changed a bit after modifying shmoverride:

[   709.756] (EE) Backtrace:
[   709.757] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5978f9]
[   709.757] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f13d1b4faaf]
[   709.758] (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0xd5) [0x7f13d1c63435]
[   709.758] (EE) 3: /usr/lib64/xorg/modules/libfb.so (fbBlt+0xee) [0x7f13cb5d992e]
[   709.759] (EE) 4: /usr/lib64/xorg/modules/libfb.so (fbBltStip+0x26) [0x7f13cb5da716]
[   709.759] (EE) 5: /usr/lib64/xorg/modules/libfb.so (fbPutZImage+0x1ba) [0x7f13cb5df73a]
[   709.759] (EE) 6: /usr/bin/X (DamageRegionAppend+0x3783) [0x521a73]
[   709.760] (EE) 7: /usr/bin/X (SyncVerifyFence+0x1f58) [0x4d40c8]
[   709.760] (EE) 8: /usr/bin/X (SyncVerifyFence+0x36c5) [0x4d73e5]
[   709.760] (EE) 9: /usr/bin/X (SendErrorToClient+0x2df) [0x436a3f]
[   709.760] (EE) 10: /usr/bin/X (remove_fs_handlers+0x453) [0x43aa53]
[   709.761] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f13d1b3b580]
[   709.761] (EE) 12: /usr/bin/X (_start+0x29) [0x424d99]
[   709.762] (EE) 13: ? (?+0x29) [0x29]

There were few reports about crashes related to OsLookupColor on the net, but they were mainly about gfx drivers. But this doesn't explain why there's a crash now but none on 3.2rc2 with identical drivers. Also none of the Qubes patches I modified AFAIK would (atleast directly) have effect on X.   Any ideas?

[mar...@wetwa.re]

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0f8acb48-7dd6-4b2c-bc59-768836c02b9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Outback Dingo,

I'd rather not distribute this ISO as it is now, since it's clearly broken and for your purposes (of getting PCI passthrough) there's quite likely many obstacles ahead before it can be really used.  But after it's made somewhat usable, I can upload it somewhere for further testing of course.

Br,
Marcus

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Aug 05, 2016 at 01:26:57PM -0700, mar...@wetwa.re wrote:
>
>
> On Friday, August 5, 2016 at 12:58:16 AM UTC+3, Marek Marczykowski-Górecki
> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >

> > On Thu, Aug 04, 2016 at 01:45:58PM -0700, mar...@wetwa.re <javascript:>

Yes, two of them:

1. It may be that radeon driver gives window buffer address directly to
the GPU and since this page(s) are mapped in dom0 from another domain, it
may cause some weird interactions, including VT-d preventing the
operation. You may try to disable compositing.

2. In both cases SEGV happens already in error handling
(SendErrorToClient+0x2df on the stack). It may be helpful to find out
what the error is. Hmm, remove_fs_handlers also looks like some cleanup
function, so the actual problem is probably a little earlier. Any more
info in the log?

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXpP0nAAoJENuP0xzK19cs++gIAJb87Yd3XisA/zNnjBa2fGai
IHzo2UtanP8zIx8HACab0QaaJdXe9rsoyJDeJ+1/VLbyd54MwRR5ZWxtijGh/YDk
WnZpI+GpONNDQ8vNiK4Y2AvhI0ANF8NhV9WvyxUclAK63WasMZKM29LKX2GDmPHF
zC3bXLVHwAzlvELGMpR+wARhFL7FloXVOIqe07d3y8djBY7grBZWxwbYhGwOsqOL
Vqcmm8HRrzF5Fv3PUtmOY29OQ6JrYr0+Mb9Lv7n2hMaYpvp76fLW0jTe6xuwd3vF
Fcn1O6+EzOSCsiPbDdhvEXeeyM2wCq1ogDCNYp/6/KC81YxtE211irU8si3AX+8=
=jFZb
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It is something else: lack of #define XC_WANT_COMPAT_MAP_FOREIGN_API in
shmoverride.c

And BTW it is not needed to include xenctrl_compat.h manually. By not
doing this, the code is compatible with both new and old Xen. See
xen-4.7 branch in marmarek/qubes-core-vchan-xen.

As for vmm-xen repository - could you rebase it on top of xen-4.6 to
cleanup history? Otherwise I would need to cherry-pick individual
commits, which will remove signatures on them.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXp/pZAAoJENuP0xzK19csfKIH/00ZxX4qaKjH30rcpo22xwz5
zW07ZoGbJXbq7IGvBOhYoxPoZgmxgbUNBGF5/bFziqSSHV5bCA094twZXGAm9zpv
Z7AHP1RC9zGNoE9E8A/QdtTjqXTHpxxGGLwz1NSP6mHrvcc7DzVnWk3p0iTN4vcE
mTOHM650grwQ2KplK8BEUE/TO8MW5VCckwf399kNBQ9iU65063r9ypq5dk5Eya+W
KE8iS/b0Zxl2jfhpgtKXOpvD7PFAtJYYUugAaymudcPa/oKvnjW+nmyOPSi6NLO2
wi5UHCkQK0Meu46o3RYNbIewFf4h/AEY2WZ743EDprpHWqBVs7Jvp7VwXiG945E=
=xjnh
-----END PGP SIGNATURE-----

[mar...@wetwa.re]

Nice! I can confirm that this fixed the Xorg crash issue (also can open normally VM windows, since shmoverride is now operating).
 

And BTW it is not needed to include xenctrl_compat.h manually. By not
doing this, the code is compatible with both new and old Xen. See
xen-4.7 branch in marmarek/qubes-core-vchan-xen.

As for vmm-xen repository - could you rebase it on top of xen-4.6 to
cleanup history? Otherwise I would need to cherry-pick individual
commits, which will remove signatures on them.

Done.  Updated also XSA182 patch formatting and removed XSA154 patch (already on Xen 4.7).

 

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXp/pZAAoJENuP0xzK19csfKIH/00ZxX4qaKjH30rcpo22xwz5
zW07ZoGbJXbq7IGvBOhYoxPoZgmxgbUNBGF5/bFziqSSHV5bCA094twZXGAm9zpv
Z7AHP1RC9zGNoE9E8A/QdtTjqXTHpxxGGLwz1NSP6mHrvcc7DzVnWk3p0iTN4vcE
mTOHM650grwQ2KplK8BEUE/TO8MW5VCckwf399kNBQ9iU65063r9ypq5dk5Eya+W
KE8iS/b0Zxl2jfhpgtKXOpvD7PFAtJYYUugAaymudcPa/oKvnjW+nmyOPSi6NLO2
wi5UHCkQK0Meu46o3RYNbIewFf4h/AEY2WZ743EDprpHWqBVs7Jvp7VwXiG945E=
=xjnh
-----END PGP SIGNATURE-----

Best regards,
Marcus
 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Aug 08, 2016 at 01:10:31PM -0700, mar...@wetwa.re wrote:
>
>
> On Monday, August 8, 2016 at 6:20:01 AM UTC+3, Marek Marczykowski-Górecki
> wrote:
> > It is something else: lack of #define XC_WANT_COMPAT_MAP_FOREIGN_API in
> > shmoverride.c
> >
>
> Nice! I can confirm that this fixed the Xorg crash issue (also can open
> normally VM windows, since shmoverride is now operating).

BTW this is already in gui-daemon master.

> > And BTW it is not needed to include xenctrl_compat.h manually. By not
> > doing this, the code is compatible with both new and old Xen. See
> > xen-4.7 branch in marmarek/qubes-core-vchan-xen.
> >
> > As for vmm-xen repository - could you rebase it on top of xen-4.6 to
> > cleanup history? Otherwise I would need to cherry-pick individual
> > commits, which will remove signatures on them.
> >
> >
> Done. Updated also XSA182 patch formatting and removed XSA154 patch
> (already on Xen 4.7).

Thanks!
I've pushed it to my github repo, with few minor additional patches.
vchan submodule still points at the old code though...

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXqPC7AAoJENuP0xzK19csCtgH/A3Eyv/inP/Qtmn/P8qXVdMu
O4FKRjx3+dTlAtVJSJNFphhJC6viUVt/JoW+NepS/579APZKIGoXebPitUs2YhOs
Arrs5xg4koqRpuKY8cvXhmnRwsnCK7A30p4IGvTSBrbyvJhmaOcOH26Vc3oPMHPM
79DTuMpQEkRRuLrWxNi/UEpzsKE3mjCjJHIu+vYPsacNnE1IiasqxLBNIwqzCFwj
MPq2nfkQBmyjID9tF4PivhVbzm1Hxd1LrFk6Fwi1ho7gq84IqD8d/2CrkL72eU8k
krrAMi6czVmnMc6NtXckGjeMb5B1i1FSm078tQajPtJjaH74VV1luj2quO9e7vM=
=SysX
-----END PGP SIGNATURE-----

[mar...@wetwa.re]

On Monday, August 8, 2016 at 11:51:14 PM UTC+3, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Aug 08, 2016 at 01:10:31PM -0700, mar...@wetwa.re wrote:
>
>
> On Monday, August 8, 2016 at 6:20:01 AM UTC+3, Marek Marczykowski-Górecki
> wrote:
> > It is something else: lack of #define XC_WANT_COMPAT_MAP_FOREIGN_API in
> > shmoverride.c
> >
>
> Nice! I can confirm that this fixed the Xorg crash issue (also can open
> normally VM windows, since shmoverride is now operating).

BTW this is already in gui-daemon master.

> > And BTW it is not needed to include xenctrl_compat.h manually. By not
> > doing this, the code is compatible with both new and old Xen. See
> > xen-4.7 branch in marmarek/qubes-core-vchan-xen.
> >
> > As for vmm-xen repository - could you rebase it on top of xen-4.6 to
> > cleanup history? Otherwise I would need to cherry-pick individual
> > commits, which will remove signatures on them.
> >
> >
> Done.  Updated also XSA182 patch formatting and removed XSA154 patch
> (already on Xen 4.7).

Thanks!
I've pushed it to my github repo, with few minor additional patches.
vchan submodule still points at the old code though...

Yes, I didn't want to pollute the history originally by making reference to my own repository, so until now I just manually edited the .gitmodules file.

Now that I look more carefully the submodule configuration, all the submodules seem to refer to certain snapshots of 3.1 release versions. For example reference to version of gui-common is also almost 1 year old.
Even by modifying .gitmodules and adding "branch = xen-4.7" to core-vchan-xen the reference stays the same and manual intervention/checkout is needed. And if the snapshot reference is updated, then this has to be redone every time a new patch is applied to the target  submodule repository.  I'm not familiar at all with these advanged git options, so what's the best way to keep track of changes in  submodules?
 

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXqPC7AAoJENuP0xzK19csCtgH/A3Eyv/inP/Qtmn/P8qXVdMu
O4FKRjx3+dTlAtVJSJNFphhJC6viUVt/JoW+NepS/579APZKIGoXebPitUs2YhOs
Arrs5xg4koqRpuKY8cvXhmnRwsnCK7A30p4IGvTSBrbyvJhmaOcOH26Vc3oPMHPM
79DTuMpQEkRRuLrWxNi/UEpzsKE3mjCjJHIu+vYPsacNnE1IiasqxLBNIwqzCFwj
MPq2nfkQBmyjID9tF4PivhVbzm1Hxd1LrFk6Fwi1ho7gq84IqD8d/2CrkL72eU8k
krrAMi6czVmnMc6NtXckGjeMb5B1i1FSm078tQajPtJjaH74VV1luj2quO9e7vM=
=SysX
-----END PGP SIGNATURE-----

Best regards,
Marcus

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Aug 09, 2016 at 02:23:02PM -0700, mar...@wetwa.re wrote:
> Now that I look more carefully the submodule configuration, all the
> submodules seem to refer to certain snapshots of 3.1 release versions. For
> example reference to version of gui-common is also almost 1 year old.
> Even by modifying .gitmodules and adding "branch = xen-4.7" to
> core-vchan-xen the reference stays the same and manual
> intervention/checkout is needed. And if the snapshot reference is updated,
> then this has to be redone every time a new patch is applied to the target
> submodule repository. I'm not familiar at all with these advanged git
> options, so what's the best way to keep track of changes in submodules?

By design submodule points at exact commit id, so in any case manual
intervention (commit) is needed. And this is actually a feature - commit
id of parent repository determine state of the whole source tree. This
makes for example tags meaningful even when submodules are used.

So the thing here is to remember (or have some external reminder) to
update submodule when needed. And in fact this "when needed" isn't
necessary each time the commit is made there.

In case of gui-common, it probably doesn't matter for now - gui agent in
stubdomain (this is why gui-common is linked there) support only very
some subset of the protocol and doesn't care about new messages. The
protocol is especially designed to allow such compatibility - gui-daemon
must be newest available, but gui-agent can be older.

But vchan submodule needs to be updated for xen 4.7, of course.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXqk0kAAoJENuP0xzK19csCvwIAIaM+mrWiDVxnyene0VPQ4oS
wcqxQBqo6HDLtscVQqIY9GPN9TOVepn/CUxsIiRvZT8/l54jchY8lFw7EzBVbpwf
ghyETSljn9TPZVBxtSmWGEl8+NaIXyTDEwj8HG81ZU+K0eKgYvMzuPnzeJmUyAww
XBHKS5FZFxmr6WAsfwLW0krt5DFJarRoRs44bTCmhgukgCU0u/QJephm37uNztn8
fZL7u7iJNGHRgJgDpZ4cIXlopHgNTpl+jUNTTd8ZR8eLniF885dsOhg3eMRGw6R6
SIjp7xmrFUShUHpsfXseuXNdTJBwZo0CRuuDzMWtw+DRbZ7LWsNq2Zx8NQMp2Ec=
=xBQN
-----END PGP SIGNATURE-----

[mar...@wetwa.re]

Ok, that makes sense. Thanks for the explanation.

The vchan-xen reference is now updated on my repo.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXqk0kAAoJENuP0xzK19csCvwIAIaM+mrWiDVxnyene0VPQ4oS
wcqxQBqo6HDLtscVQqIY9GPN9TOVepn/CUxsIiRvZT8/l54jchY8lFw7EzBVbpwf
ghyETSljn9TPZVBxtSmWGEl8+NaIXyTDEwj8HG81ZU+K0eKgYvMzuPnzeJmUyAww
XBHKS5FZFxmr6WAsfwLW0krt5DFJarRoRs44bTCmhgukgCU0u/QJephm37uNztn8
fZL7u7iJNGHRgJgDpZ4cIXlopHgNTpl+jUNTTd8ZR8eLniF885dsOhg3eMRGw6R6
SIjp7xmrFUShUHpsfXseuXNdTJBwZo0CRuuDzMWtw+DRbZ7LWsNq2Zx8NQMp2Ec=
=xBQN
-----END PGP SIGNATURE-----

Best regards,
Marcus

[Outback Dingo]

Hi Marcus, has progress been made on this, Im getting 0 support from qubes in relation to my pci network issues

Im hoping that at some point you might have a more viable solution to try.

--

You received this message because you are subscribed to the Google Groups "qubes-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5cdced0e-21a1-4842-9e20-98dacc72ff76%40googlegroups.com.