On 17.09.2019 00:20, Joe Jin wrote:
> On 9/16/19 1:01 AM, Jan Beulich wrote:
>> On 13.09.2019 18:38, Joe Jin wrote:
>>> On 9/13/19 12:14 AM, Jan Beulich wrote:
On 12.09.2019 20:03, Joe Jin wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -412,6
flight 141383 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
This allows in particular some streamlining of the TLB flushing code
paths.
Signed-off-by: Jan Beulich
---
v2: Avoid #ifdef in cr3_pcid().
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -24,6 +24,11 @@
#define WRAP_MASK (0x03FFU)
#endif
+#ifndef CONFIG_PV
+# undef X86_CR4
PCID validly depends on LM, as it can be enabled in Long Mode only.
INVPCID, otoh, can be used not only without PCID enabled, but also
outside of Long Mode altogether. In both cases its functionality is
simply restricted to PCID 0, which is sort of expected as no other PCID
can be activated there.
Eliminate the not really useful local variable "old". Reduce the scope
of "page". Rename the latched "current".
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v2: Re-base over change earlier in the series.
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2296,10 +2296,
There's no need to re-obtain a page reference if only bits not affecting
the address change.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2325,7 +2325,7 @@ int hvm_set_cr3(unsigned long value, boo
}
if ( hvm_pa
While bits 11 and below are, if not used for other purposes, reserved
but ignored, bits beyond physical address width are supposed to raise
exceptions (at least in the non-nested case; I'm not convinced the
current nested SVM/VMX behavior of raising #GP(0) here is correct, but
that's not the subjec
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2080,6 +2080,8 @@ static int hvmemul_write_cr(
HVMTRACE_LONG_2D(CR_WRITE, r
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
Hi Peter,
Could you review this version?
Thank you,
On Fri, 6 Sep 2019 22:13:37 +0900
Masami Hiramatsu wrote:
> Hi,
>
> Here is the 4th version of patches to handle Xen/KVM emulate
> prefix by x86 instruction decoder.
>
> These patches allow x86 instruction decoder to decode
> Xen and KVM e
We really need to flush the TLB just once, if we do so with or after the
CR3 write. The only case where two flushes are unavoidable is when we
mean to turn off CR4.PGE (perhaps just temporarily; see the code
comment).
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/fl
There's no need for it to be 64 bits wide - only the low twelve bits
of CR3 hold the PCID.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -103,7 +103,8 @@ static void do_tlb_flush(void)
void switch_cr3_cr4(unsigned long
On 16.09.2019 20:08, Oleksandr wrote:
> On 16.09.19 13:40, Jan Beulich wrote:
>>> +/* per-device IOMMU instance data */
>>> +struct iommu_fwspec {
>>> +/* this device's IOMMU */
>>> +struct device *iommu_dev;
>>> +/* IOMMU driver private data for this device */
>>> +void *iommu_priv
Various CR3 and PCID related adjustments, first and foremost an
almost full re-write of switch_cr3_cr4() (in patch 2).
1: x86: adjust cr3_pcid() return type
2: x86: limit the amount of TLB flushing in switch_cr3_cr4()
3: x86/mm: honor opt_pcid also for 32-bit PV domains
4: x86/HVM: move NOFLUSH ha
flight 141354 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 141364 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141004
Tests which did
flight 141356 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141356/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141241
test-armhf-armhf-libvirt-raw 13 saveresto
flight 141378 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141348 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 140282
Tests which are f
On 9/16/19 1:01 AM, Jan Beulich wrote:
> On 13.09.2019 18:38, Joe Jin wrote:
>> Hi Jan,
>>
>> Thanks for your reply, see my reply in line please.
>>
>> On 9/13/19 12:14 AM, Jan Beulich wrote:
>>> On 12.09.2019 20:03, Joe Jin wrote:
With below testcase, guest kernel reported "No irq handler for
flight 141346 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141346/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade broken
test-amd64-amd64-xl-
> On Sep 16, 2019, at 12:31 PM, Laszlo Ersek wrote:
>
> On 09/16/19 20:36, Andrew Fish wrote:
>>
>>
>>> On Sep 16, 2019, at 10:36 AM, Laszlo Ersek wrote:
>>>
>>> On 09/13/19 16:50, Anthony PERARD wrote:
This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
using the Me
flight 141371 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
From: Dongli Zhang
Date: Mon, 16 Sep 2019 11:46:59 +0800
> When skb_shinfo(skb) is not able to cache extra fragment (that is,
> skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
> the sk_buff_head list is already empty. As a result, cons is increased only
> by 1 and returns
On 09/16/19 20:36, Andrew Fish wrote:
>
>
>> On Sep 16, 2019, at 10:36 AM, Laszlo Ersek wrote:
>>
>> On 09/13/19 16:50, Anthony PERARD wrote:
>>> This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
>>> using the Memory Allocation Services.
>>>
>>> This comes with a new interface na
> On Sep 16, 2019, at 10:36 AM, Laszlo Ersek wrote:
>
> On 09/13/19 16:50, Anthony PERARD wrote:
>> This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
>> using the Memory Allocation Services.
>>
>> This comes with a new interface named RegisterExitCallback so that PV
>> drivers
On 16.09.19 13:37, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,15 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
On 16.09.19 13:40, Jan Beulich wrote:
Hi, Jan
+
+/* per-device IOMMU instance data */
+struct iommu_fwspec {
+/* this device's IOMMU */
+struct device *iommu_dev;
+/* IOMMU driver private data for this device */
+void *iommu_priv;
+/* number of associated device IDs */
+
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a
On 09/13/19 16:50, Anthony PERARD wrote:
> This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
> using the Memory Allocation Services.
>
> This comes with a new interface named RegisterExitCallback so that PV
> drivers can disconnect from the backend before XenBusDxe is teared
> down
On 16.09.19 16:39, Jan Beulich wrote:
On 16.09.2019 14:49, Juergen Gross wrote:
On 16.09.19 11:20, Jan Beulich wrote:
On 14.09.2019 08:42, Juergen Gross wrote:
vcpu_force_reschedule() is only used for modifying the periodic timer
of a vcpu. Forcing a vcpu to give up the physical cpu for that p
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
snip
+/*
+ * Parse user provided action flags.
+ * This function expects to only receive an array of input parameters being
flags.
+ * Expected action is specified via idx paramater (index of flag_options[]).
+ */
+static int get_flags(int argc, c
Paul,
I am still trying to understand the current status. You mentioned "without
having to enable debugging within the guest". Does that mean we will need
to monitor all the debug exceptions, and see if one of these was because of
us or them? Also, wouldn't setting breakpoints require us to modify
On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any hotpatches built for diff
On 09/13/19 16:50, Anthony PERARD wrote:
> XsRead and XsBackendRead of the XENBUS_PROTOCOL return allocated
> memory but this isn't allowed during the ExitBootServices call. We
> need XsRead and XsBackendRead to disconnect from the device so
> XENBUS_PROTOCOL is changed to use a buffer supplied by
On 09/13/19 16:50, Anthony PERARD wrote:
> We will use a buffer on the stack instead of allocating memory for
> internal functions that are expecting a reply from xenstore.
>
> The external interface XENBUS_PROTOCOL isn't changed yet, so
> allocation are made for XsRead and XsBackendRead.
>
> Ref:
flight 141345 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken
test-amd64-amd64-libvirt-xsm
On 16.09.2019 17:49, Andrew Cooper wrote:
> On 16/09/2019 12:17, Jan Beulich wrote:
>> On 13.09.2019 21:27, Andrew Cooper wrote:
>>> -static void intel_xc_cpuid_policy(const struct cpuid_domain_info *info,
>>> - const unsigned int *input, unsigned int
>>> *regs)
>>
On 16.09.2019 10:10, Alexandru Stefan ISAILA wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3224,6 +3224,14 @@ static enum hvm_translation_result __hvm_copy(
> return HVMTRANS_bad_gfn_to_mfn;
> }
>
> +if ( unlikely(v->arch.vm_event) &&
> +
On 16/09/2019 12:22, Jan Beulich wrote:
> On 13.09.2019 21:27, Andrew Cooper wrote:
>> The domain builder no longer uses local CPUID instructions for policy
>> decisions. This resolves a key issue for PVH dom0's. However, as PV dom0's
>> have never had faulting enforced, leave a command line opti
On 16/09/2019 12:17, Jan Beulich wrote:
> On 13.09.2019 21:27, Andrew Cooper wrote:
>> -static void intel_xc_cpuid_policy(const struct cpuid_domain_info *info,
>> - const unsigned int *input, unsigned int
>> *regs)
>> -{
>> -switch ( input[0] )
>> -{
>> -
On 16.09.2019 17:26, Andrew Cooper wrote:
> On 16/09/2019 11:56, Jan Beulich wrote:
>> On 13.09.2019 21:27, Andrew Cooper wrote:
>>> --- a/tools/tests/cpu-policy/test-cpu-policy.c
>>> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
>>> @@ -283,7 +283,7 @@ static void test_cpuid_deserialise_failure(v
On 16.09.2019 16:50, Andrew Cooper wrote:
> After a complicated investigation, it turns out that c/s 2529c850ea48
> broke xc_vcpu_getinfo().
>
> The bug looks as if it is in vcpu_runstate_get(), which doesn't account
> for XEN_RUNSTATE_UPDATE and calculating a wildly inappropriate delta.
> Ultima
On 09/16/19 17:39, Laszlo Ersek wrote:
> On 09/13/19 16:50, Anthony PERARD wrote:
>> When doing an action with a path and subpath in the xenstore,
>> XenStoreJoin is called to generate "$path/$subpath". But this function
>> do an allocation of memory which isn't necessary. Instead we will
>> constr
On 16/09/2019 12:09, Jan Beulich wrote:
> On 13.09.2019 21:27, Andrew Cooper wrote:
>> @@ -932,6 +932,13 @@ int xc_cpuid_set(
>> goto fail;
>> }
>>
>> +/*
>> + * Notes for following this algorithm:
>> + *
>> + * While it will accept any leaf d
On 09/13/19 16:50, Anthony PERARD wrote:
> This patch rework XenStoreProcessMessage in order to avoid memory
> allocation when a reply is expected. Instead of allocating a buffer
> for this reply, we are going to copy to a buffer passed by the caller.
> For messages that aren't fully received, they
On 16/09/2019 12:04, Jan Beulich wrote:
> On 13.09.2019 21:27, Andrew Cooper wrote:
>> v2:
>> * Bump the DOMCTL interface version
>> * Proactively set the error pointers in xc_set_domain_cpu_policy()
> From this I would have expected ...
>
>> --- a/tools/libxc/xc_cpuid_x86.c
>> +++ b/tools/libxc/
On 09/13/19 16:50, Anthony PERARD wrote:
> When doing an action with a path and subpath in the xenstore,
> XenStoreJoin is called to generate "$path/$subpath". But this function
> do an allocation of memory which isn't necessary. Instead we will
> construct the path with WRITE_REQUEST and data used
flight 141369 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On 16/09/2019 11:59, Jan Beulich wrote:
> On 13.09.2019 21:27, Andrew Cooper wrote:
>> --- /dev/null
>> +++ b/xen/lib/x86/policy.c
>> @@ -0,0 +1,54 @@
>> +#include "private.h"
>> +
>> +#include
>> +
>> +int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>> +
Hi Julien,
Julien Grall writes:
> Hi,
>
> On 9/12/19 8:45 PM, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>>
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 9/11/19 7:48 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
> Hi Volodymyr,
>
> On 8/23/19 7:48 PM, Vol
On 16.09.2019 17:03, Oleksandr wrote:
> On 16.09.19 13:13, Jan Beulich wrote:
>> On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
>>> --- a/xen/common/xmalloc_tlsf.c
>>> +++ b/xen/common/xmalloc_tlsf.c
>>> @@ -598,6 +598,58 @@ void *_xzalloc(unsigned long size, unsigned long align)
>>> return
Hi Julian,
The KDD code has been untouched for many years; the last OS that it
appears to have been tried with is Win7 SP1. However, debugging a
Windows guest with emulated serial is very slow and clunky so a
solution like KDD is very desirable.
The goal of a project would be to get the code f
On 16.09.19 13:13, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -598,6 +598,58 @@ void *_xzalloc(unsigned long size, unsigned long align)
return p ? memset(p, 0, size) : p;
}
+void *_x
> -Original Message-
> From: Anthony PERARD
> Sent: 16 September 2019 15:06
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Christian Lindig
> ; Ian Jackson ; Wei Liu
> ; Andrew
> Cooper ; George Dunlap ;
> Julien Grall
> ; Konrad Rzeszutek Wilk ;
> Stefano St
Hello,
After a complicated investigation, it turns out that c/s 2529c850ea48
broke xc_vcpu_getinfo().
The bug looks as if it is in vcpu_runstate_get(), which doesn't account
for XEN_RUNSTATE_UPDATE and calculating a wildly inappropriate delta.
Ultimately, the result of XEN_DOMCTL_getvcpuinfo end
On 09/13/19 16:50, Anthony PERARD wrote:
> In order to be able to use XenStoreVSPrint during the
> ExitBootServices, we remove the allocation done by the function and
> use the stack instead.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
> Signed-off-by: Anthony PERARD
> ---
> Ovm
On 16.09.2019 14:49, Juergen Gross wrote:
> On 16.09.19 11:20, Jan Beulich wrote:
>> On 14.09.2019 08:42, Juergen Gross wrote:
>>> vcpu_force_reschedule() is only used for modifying the periodic timer
>>> of a vcpu. Forcing a vcpu to give up the physical cpu for that purpose
>>> is kind of brutal.
On 09/13/19 16:50, Anthony PERARD wrote:
> This patch rework the reception of xenstore watch event to avoid
> allocation.
>
> Instead of queuing watch events, we simply mark a XENSTORE_WATCH as
> "triggered". We don't need to know how many time we received the
> event, only that it happened. That
On 09/13/19 16:50, Anthony PERARD wrote:
> Rework XenStoreFindWatch() to be able to search for a registered watch
> with a pointer instead of a string.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/XenBusDxe/XenStore.c | 20 +
Hi Paul,
Thanks for getting back to us in regards to the KDD project. I am trying to
understand the current status of the project. Could you provide a bit more
information on the current status and what would need to be done.
Julian
On Mon, Sep 16, 2019 at 5:53 AM Paul Durrant wrote:
> I think
On 09/13/19 16:50, Anthony PERARD wrote:
> Fix missing \n in DEBUG messages in XenBusDxe and use DEBUG_*.
>
> Signed-off-by: Anthony PERARD
> ---
> OvmfPkg/XenBusDxe/EventChannel.c | 3 ++-
> OvmfPkg/XenBusDxe/XenStore.c | 6 +++---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> dif
On Mon, Sep 16, 2019 at 10:27:08AM +0100, Paul Durrant wrote:
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 59dbcb50a0..7afae81432 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -30,6 +30,12 @@
> int libxl__domain_create_info_setd
> -Original Message-
> From: Wei Liu
> Sent: 16 September 2019 14:29
> To: Andrew Cooper
> Cc: Paul Durrant ; Xen-devel
> ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
>
> Subject: Re: [PATCH] x86/viridian: Reword HV_X64_MSR_CRASH_CTL print message
>
> On Mon, 16 Sep 2019 at 14:13, Andr
On Mon, 16 Sep 2019 at 12:17, Jan Beulich wrote:
>
> On 13.09.2019 21:27, Andrew Cooper wrote:
> > -static void intel_xc_cpuid_policy(const struct cpuid_domain_info *info,
> > - const unsigned int *input, unsigned int
> > *regs)
> > -{
> > -switch ( input[0] )
On Mon, 16 Sep 2019 at 14:13, Andrew Cooper wrote:
[...]
> Replace the VIRIDIAN prefix with 'reported' to reduce the confusion to
> non-xen-developers trying to interpret the message.
> >>> This is a message that is peculiar to Windows VMs, so how about "Windows
> >>> VM CRASH"?
> >> I
On 16/09/2019 13:56, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 16 September 2019 13:48
>> To: Paul Durrant ; Xen-devel
>>
>> Cc: Jan Beulich ; Wei Liu ; Roger Pau Monne
>>
>> Subject: Re: [PATCH] x86/viridian: Reword HV_X64_MSR_CRASH_CTL print message
>>
> -Original Message-
> From: Andrew Cooper
> Sent: 16 September 2019 13:48
> To: Paul Durrant ; Xen-devel
>
> Cc: Jan Beulich ; Wei Liu ; Roger Pau Monne
>
> Subject: Re: [PATCH] x86/viridian: Reword HV_X64_MSR_CRASH_CTL print message
>
> On 15/09/2019 12:51, Paul Durrant wrote:
> >>
On 16.09.19 11:20, Jan Beulich wrote:
On 14.09.2019 08:42, Juergen Gross wrote:
vcpu_force_reschedule() is only used for modifying the periodic timer
of a vcpu. Forcing a vcpu to give up the physical cpu for that purpose
is kind of brutal.
So instead of doing the reschedule dance just operate o
On 15/09/2019 12:51, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 13 September 2019 17:04
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Wei Liu ;
>> Roger Pau Monne ; Paul Durrant
>>
>> Subject: [PATCH] x86/viridian: Reword HV_X64_MSR_CRASH_CTL p
flight 141362 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141362/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
I think KDD is still a worthy thing to do, particularly in light of
https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg01723.html
(which is about the most recent ref I could find, and I don't know
what happened to the code after that). AFAIK, the biggest challenge is
getting round Windows' KA
flight 141339 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 broken
test-amd64-i386-xl-qemut-stubdom
Extend the XC python bindings library to support also all common
livepatch operations and actions.
Add the python bindings for the following operations:
- status (pyxc_livepatch_status):
Requires a payload name as an input.
Returns a status dict containing a state string and a return code
in
Strip all unneeded metadata symbols from generated hotpatch modules.
The metadata symbols are the symbols from metadata-like sections (e.g.
'.livepatch.funcs') or livepatch hooks symbols (defined by a set of
prefixes. E.g. 'livepatch_load_data_').
By default the create-diff-object does not create
In the process of creating a final hotpatch module file make sure to
strip all transient symbols that have not been caught and removed by
create-diff-object processing. For now these are only the hooks
kpatch load/unload symbols.
For all new object files that are carried along for the final linkin
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
With stacked hotpatch modules it is essential that each and every
hotpatch is verified against the hypervisor bu
Extend livepatch_patch_func to support a new field: expect. This new
field describes the expected data, its length and whether expectation
is enabled. The expectation's data is of opaque padding size.
By default the expectation field is zero-out and the expectation is
disabled unless explicitly sp
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-byte alignment padding to reserve
place for future flags and options.
The new fields are zero-out upon .livepatch.funcs section creation.
Include new sections containing optional apply and revert action
hooks.
The following new section names are supported:
- .livepatch.hooks.apply
- .livepatch.hooks.revert
Signed-off-by: Pawel Wieczorkiewicz
---
create-diff-object.c | 10 ++
1 file changed, 10 insertions(+)
diff --gi
Include new sections containing optional pre-, post- action hooks.
The following new section names are supported:
- .livepatch.hooks.preapply
- .livepatch.hooks.postapply
- .livepatch.hooks.prerevert
- .livepatch.hooks.postrevert
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Ross Lage
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
IMPROVEMENTS:
1. Strip redundant or transient symbols from resulting object files:
[6], [7]
This c
On 13.09.2019 21:27, Andrew Cooper wrote:
> The domain builder no longer uses local CPUID instructions for policy
> decisions. This resolves a key issue for PVH dom0's. However, as PV dom0's
> have never had faulting enforced, leave a command line option to restore the
> old behaviour.
>
> Adver
On 13.09.2019 21:27, Andrew Cooper wrote:
> -static void intel_xc_cpuid_policy(const struct cpuid_domain_info *info,
> - const unsigned int *input, unsigned int
> *regs)
> -{
> -switch ( input[0] )
> -{
> -case 0x0004:
> -/*
> - * EA
On 13.09.2019 21:27, Andrew Cooper wrote:
> @@ -932,6 +932,13 @@ int xc_cpuid_set(
> goto fail;
> }
>
> +/*
> + * Notes for following this algorithm:
> + *
> + * While it will accept any leaf data, it only makes sense to use on
> + * f
On 16.09.19 12:53, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -239,6 +239,16 @@ struct iommu_ops {
int __must_check (*iotlb_flush_all)(struct domain *d);
int (*get_reserved_device_memor
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically supp
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation require
This is the initial implementation of the expectations enhancement
to improve inline asm hotpatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm hotpatching. The flag enabled allows
to control the expectation state.
Each expectation has data
Having detailed hotpatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
hotpatch loads in the system (at least within dmesg buffer size
limits).
The hotpatch metadata are embedded in a form of .modinfo section.
Each such section cont
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent appl
Extend the XC python bindings library to support also all common
livepatch operations and actions.
Add the python bindings for the following operations:
- status (pyxc_livepatch_status):
Requires a payload name as an input.
Returns a status dict containing a state string and a return code
in
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any hotpatches built for different
hypervisor version as indicated by the Xen Bu
By default Livepatch enforces the following buildid-based dependency
chain between hotpatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper hotpatch stack order is maintained and enforced.
While it is
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
Main changes in v3:
- Fix expectation test to work on Arm
- Add test for metadata (Konrad)
- Minor fixes
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the hotpatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a hotpatch may be
constructed of only hooks to perfor
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is
On 13.09.2019 21:27, Andrew Cooper wrote:
> v2:
> * Bump the DOMCTL interface version
> * Proactively set the error pointers in xc_set_domain_cpu_policy()
From this I would have expected ...
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -229,6 +229,52 @@ int xc_get_
1 - 100 of 133 matches
Mail list logo
