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
https://lists.xenproject.org/mailman/listinfo/
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
___
Xen-
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 Beu
> -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 St
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 2
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 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 Co
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 xen
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 tes
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 prot
...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
hard
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 acce
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 do
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 qu
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 @@ protmode_load_seg(
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 t
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 IS_ENABLED(CONFIG_ZONE_D
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 (*du
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 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 path
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, un
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 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.
>
> Furthermore
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 a
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 wrote:
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 maint
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 th
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 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 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,
> +
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 al
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_
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
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 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
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
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 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
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
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
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
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 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:
> 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
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
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
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
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
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
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
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
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 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 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
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
> -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/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
>>
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 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] )
> -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, 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
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
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:
> 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 +
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.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:
> 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
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
> -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
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
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.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 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 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,
>> +
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 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
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:
> 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: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/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 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 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 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 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 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 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)
>>
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 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 diff
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
1 - 100 of 133 matches
Mail list logo
