|
From: Olaf H. <ol...@ae...> - 2018-02-22 13:34:52
|
In coregrind/m_syswrap/syswrap-xen.c the handlers of sysctl and domctl check the current ->interface_version. If it is not yet known, an error is reported. Otherwise the current ->cmd is processed. Several commands handle various ->interface_version. But none of these handlers have a concept of "use the latest". If a new interface_version is added at the beginning of the list, each and every handler must be updated with the newly added version number. I think it would be simpler to check the supported versions as it is done now, then each handler uses the latest layout in a "default:" case. A picture to show what I mean:
index 54153ab1c..910869ff6 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -821,7 +821,7 @@ PRE(domctl)
case 0x0000000a:
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_00000007, machine_sbdf);
break;
- case 0x0000000b:
+ default:
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_0000000b, dev);
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_0000000b, flag);
switch (domctl->u.assign_device_0000000b.dev) {
That may fix d73f2c748, which just added a new global version without adjusting every other ->interface_version check. XEN_DOMCTL_test_assign_device, for example, might have been unchanged in xen-4.6, but now valgrind does not handle it anymore.
Olaf
|
|
From: Olaf H. <ol...@ae...> - 2018-02-27 17:45:53
|
Am Fri, 16 Feb 2018 12:52:21 +0100 schrieb Olaf Hering <ol...@ae...>: > In coregrind/m_syswrap/syswrap-xen.c ... So, looks like the Xen part is orphaned. How do we move forward? Am I allowed to adopt it? Olaf |