> -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 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(-)
>
>
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 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 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
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.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)
>>>
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 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 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,
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 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 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
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 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:
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 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,
>> +
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
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] )
>> -{
>> -
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 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
> -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
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:
> 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 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 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/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 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 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
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 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.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
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 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 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 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 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 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 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 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
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
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
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
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 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
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 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
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 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 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
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
From: Paul Durrant
Date: Fri, 13 Sep 2019 13:47:27 +0100
> My Citrix email address will expire shortly.
>
> Signed-off-by: Paul Durrant
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 13.09.2019 18:20, Andrew Cooper wrote:
> ERST isn't a mandatory table, and also isn't very common to find. The message
> is unnecessary noise during boot. Furthermore, it is redundant with the list
> of found ACPI tables printed just ahead.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan
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 vector":
>>> 1). Passthrough mlx ib VF to
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind
On 15.09.2019 19:51, Julien Grall wrote:
> Hi,
>
> On 9/15/19 3:09 PM, osstest service owner wrote:
>> flight 141333 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/141333/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including
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 the timer
> directly. By
On 13.09.2019 18:16, Andrew Cooper wrote:
> Printing "$foo disabled" is unnecessary noise during boot. All other VPMU
> settings emit a message, so this doesn't result in any ambiguity.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
> -Original Message-
> From: Anthony PERARD
> Sent: 13 September 2019 17:29
> 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
On 16.09.2019 05:18, Chao Gao wrote:
> On Fri, Sep 13, 2019 at 11:14:59AM +0200, Jan Beulich wrote:
>> On 12.09.2019 09:22, Chao Gao wrote:
>>> @@ -354,6 +360,50 @@ static void set_state(unsigned int state)
>>> smp_wmb();
>>> }
>>>
>>> +static int secondary_thread_work(void)
>>> +{
>>> +
I guess this still needs ARM and toolstack acks?
> -Original Message-
> From: Paul Durrant
> Sent: 13 September 2019 11:58
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Roger Pau Monne
> ; Jan Beulich
> ; Christian Lindig ; David
> Scott ;
> Ian Jackson ; Wei Liu ; Andrew
flight 141337 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141337/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken
test-amd64-amd64-xl-qemuu-ovmf-amd64
flight 141357 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
test-armhf-armhf-xl 7
...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 in xl.cfg, or implicitly if there is passthrough
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 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
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:
> -/*
> - *
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.
>
>
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
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
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
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
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
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
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
I've noticed the issue the 1st patch means to address only while
putting together the 2nd. Considering the other Hygon enablement
in this release cycle I think we want patch 1 for 4.13. Patch 2
should be considered too, but we've been effectively mis-emulating
MOVSXD on modern Intel hardware for
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1995,7 +1995,8 @@
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
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
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 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/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 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 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
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:
> 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
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
Using memcpy() may result in multiple individual byte accesses
(dependening how memcpy() is implemented and how the resulting insns,
e.g. REP MOVSB, get carried out in hardware), which isn't what we
want/need for carrying out guest insns as correctly as possible. Fall
back to memcpy() only for
On Fri, Sep 13, 2019 at 10:47:38AM +0100, Paul Durrant wrote:
> This patch defines a new bit reported in the hw_cap field of struct
> xen_sysctl_physinfo to indicate whether the platform supports sharing of
> HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
> whether the
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 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 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.
>
>
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
1 - 100 of 117 matches
Mail list logo
