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
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
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
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
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
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
> 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
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
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
> 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
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
>
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
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,
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
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
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
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
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.
>
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
>>
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
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,
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
>> +++
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
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,
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)
>>>
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
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
> -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
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
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
> ---
>
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
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(-)
>
>
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
> -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,
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
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
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'
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
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
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
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
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
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
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
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
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.
>
>
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:
> -/*
> - *
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
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
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
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
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
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
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
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
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure
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,
> +const struct cpu_policy *guest,
> +
On Mon, 16 Sep 2019 at 10:47, Jan Beulich wrote:
>
> For some reason the Hygon enabling series left out the insn emulator.
> Make appropriate adjustments wherever we've been special casing AMD.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
On Sat, 14 Sep 2019 at 16:38, Marek Marczykowski-Górecki
wrote:
>
> Add libxc wrapper for PHYSDEVOP_interrupt_control introduced in previous
> commit.
>
> Signed-off-by: Marek Marczykowski-Górecki
Subject to acceptance of earlier patches.
Acked-by: Wei Liu
On 13.09.2019 21:27, Andrew Cooper wrote:
> The control domain exclusion for CPUID Faulting predates dom0 PVH, but the
> reason for the exclusion (to allow the domain builder to see host CPUID
> values) isn't applicable.
>
> The domain builder *is* broken in PVH control domains, and restricting
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
> --- /dev/null
> +++ b/xen/include/asm-arm/iommu_fwspec.h
> @@ -0,0 +1,68 @@
> +/*
> + * xen/include/asm-arm/iommu_fwspec.h
> + *
> + * Contains a common structure to hold the per-device firmware data and
> + * declaration of functions used to
Hi Julian
For the KDD related project I have CC'ed Paul.
I have gathered some ideas for cleaning up hypervisor code but they are
of lower difficulty compared to other projects. They are definitively
not as fun as the others. ;-)
Wei.
On Mon, Sep 09, 2019 at 08:58:51AM +0100, Julien Grall
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))
>
> +/* Allocate space for a structure with
On Fri, Sep 13, 2019 at 11:39:53AM +0100, Julien Grall wrote:
> At the moment, early printk can only be configured on the make command
> line. It is not very handy because a user has to remove the option
> everytime it is using another command other than compiling the
> hypervisor.
>
>
On 9/16/19 10:27 AM, Paul Durrant wrote:
> ...and hence the ability to disable IOMMU mappings, and control EPT
> sharing.
>
> This patch introduces a new 'libxl_passthrough' enumeration into
> libxl_domain_create_info. The value will be set by xl either when it parses
> a new 'passthrough' option
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 *_xrealloc(void *ptr, unsigned long size,
On Fri, Sep 06, 2019 at 02:41:03PM +0200, Juergen Gross wrote:
> The Makefile below tools/libs have a lot in common. Put those common
> parts into a new libs.mk and include that from the specific Makefiles.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - include common Makefile via absolute
On Tue, Sep 03, 2019 at 09:20:23AM +0200, Juergen Gross wrote:
> The Makefile below tools/libs have a lot in common. Put those common
> parts into a new libs.mk and include that from the specific Makefiles.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
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_memory)(iommu_grdm_t *, void *);
> void
From: Peng Fan
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So add a check if CONFIG_ZONE_DMA32 is enabled use __GFP_DMA32.
Signed-off-by: Peng Fan
---
V3:
Use
XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
memory (or register) when used without REX.W and with operand size
override. Since the upper 16 bits of the value read won't be used
anyway in this case, make
1 - 100 of 117 matches
Mail list logo
