Dear maintainers for Xen Project,
I am writing you to report a bug due to the unreleased lock. The
impact could be deadlock or memory consumption. In the function of
read_watch_internal, the mutex lock h->watch_mutex (Line901) is not released
correctly when read_message(h,nonblo
When the kdump/kexec is enabled at HVM VM side, to panic kernel will trap
to xen side with reason=soft_reset. As a result, the xen will reboot the VM
with the kdump kernel.
Unfortunately, when the VM is panic with below command line ...
"taskset -c 33 echo c > /proc/sysrq-trigger"
... the kdump
The guest may access the pv vcpu_time_info immediately after
VCPUOP_register_vcpu_info. This is to borrow the idea of
VCPUOP_register_vcpu_time_memory_area, where the
force_update_vcpu_system_time() is called immediately when the new memory
area is registered.
Otherwise, we may observe clock drift
The sched_clock() can be used very early since upstream
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with upstream commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock
time from 0"), kdump kernel in Xen HVM guest may panic at very early stage
when accessing &__t
Hi Stefano,
> On 11 Oct 2021, at 20:27, Stefano Stabellini wrote:
>
> On Mon, 11 Oct 2021, Oleksandr Andrushchenko wrote:
>> On 11.10.21 20:15, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
On Mon, Oct 11, 2021 at 04:20:14PM +, O
Hi Luca,
> On 11 Oct 2021, at 19:15, Luca Fancellu wrote:
>
> This patch introduces the support for dom0less configuration
> when using UEFI boot on ARM, it permits the EFI boot to
> continue if no dom0 kernel is specified but at least one domU
> is found.
>
> Introduce the new property "xen,ue
On 11.10.2021 20:18, Stefano Stabellini wrote:
> On Mon, 11 Oct 2021, Jan Beulich wrote:
>> On 11.10.2021 15:34, Bertrand Marquis wrote:
On 11 Oct 2021, at 14:09, Jan Beulich wrote:
On 11.10.2021 14:41, Bertrand Marquis wrote:
> But digging deeper into this, I would have 2 questions:
On 11.10.2021 19:07, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 05:31:08PM +0200, Jan Beulich wrote:
>> On 11.10.2021 16:58, Anthony PERARD wrote:
>>> On Mon, Oct 11, 2021 at 12:56:54PM +0200, Jan Beulich wrote:
On 24.08.2021 12:50, Anthony PERARD wrote:
> With nearly everything neede
> On 12 Oct 2021, at 02:31, Stefano Stabellini wrote:
>
> On Mon, 11 Oct 2021, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/10/2021 22:24, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 840728d6c0..076b827bdd 100644
---
This patch series is a rework of an already pushed patch
exposing PMU to the guests. Since the second version the vpmu
parameter is common and prework in the form of reporting
availability of vPMU on the hardware is added.
The third version of the patch series removes the redundant check
from x86
Introduce flag XEN_SYSCTL_PHYSCAP_vpmu which
indicates whether the platform supports vPMU
functionality. Modify Xen and tools accordingly.
Take the opportunity and fix XEN_SYSCTL_PHYSCAP_vmtrace
definition in sysctl.h which wrongly use (1 << 6)
instead of (1u << 6).
Signed-off-by: Michal Orzel
R
ID_AA64DFR0_EL1/ID_DFR0_EL1 registers provide
information about PMU support. Replace structure
dbg64/dbg32 with a union and fill in all the
register fields according to document:
ARM Architecture Registers(DDI 0595, 2021-06).
Add macros boot_dbg_feature64/boot_dbg_feature32
to check for a debug fe
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps(currently only for ARM).
The current status is that the PMU registers are not
virtualized and the physical registers are directly
accessible when this parameter is enabled. There i
On 12.10.21 08:54, Ryan Cai wrote:
Dear maintainers for Xen Project,
I am writing you to report a bug due to the unreleased
lock. The impact could be deadlock or memory consumption. In the
function of /read_watch_internal/, the mutex lock /h->watch_mutex/
(*Line901*) is not rele
On 12 Oct 2021, at 09:13, Michal Orzel
mailto:michal.or...@arm.com>> wrote:
This patch series is a rework of an already pushed patch
exposing PMU to the guests. Since the second version the vpmu
parameter is common and prework in the form of reporting
availability of vPMU on the hardware is add
On 11.10.2021 19:11, Bertrand Marquis wrote:
>> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
>> On Mon, Oct 11, 2021 at 02:16:19PM +, Bertrand Marquis wrote:
On 11 Oct 2021, at 14:57, Roger Pau Monné wrote:
I think the commit message needs to at least be expanded in order to
>>>
On 12.10.2021 09:24, Dongli Zhang wrote:
> The guest may access the pv vcpu_time_info immediately after
> VCPUOP_register_vcpu_info. This is to borrow the idea of
> VCPUOP_register_vcpu_time_memory_area, where the
> force_update_vcpu_system_time() is called immediately when the new memory
> area is
Hi Jan,
> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>
> On 11.10.2021 19:11, Bertrand Marquis wrote:
>>> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
>>> On Mon, Oct 11, 2021 at 02:16:19PM +, Bertrand Marquis wrote:
> On 11 Oct 2021, at 14:57, Roger Pau Monné wrote:
> I thin
On 11.10.2021 20:15, Luca Fancellu wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -166,6 +166,13 @@ static void __init PrintErr(const CHAR16 *s)
> StdErr->OutputString(StdErr, (CHAR16 *)s );
> }
>
> +#ifndef CONFIG_HAS_DEVICE_TREE
> +static inline int __init efi_che
On 12.10.21 09:24, Dongli Zhang wrote:
When the kdump/kexec is enabled at HVM VM side, to panic kernel will trap
to xen side with reason=soft_reset. As a result, the xen will reboot the VM
with the kdump kernel.
Unfortunately, when the VM is panic with below command line ...
"taskset -c 33 echo
On 12.10.21 09:24, Dongli Zhang wrote:
The sched_clock() can be used very early since upstream
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with upstream commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock
time from 0"), kdump kernel in Xen HVM guest may pani
> On 12 Oct 2021, at 09:45, Jan Beulich wrote:
>
> On 11.10.2021 20:15, Luca Fancellu wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -166,6 +166,13 @@ static void __init PrintErr(const CHAR16 *s)
>> StdErr->OutputString(StdErr, (CHAR16 *)s );
>> }
>>
>> +#ifnde
On 11.10.2021 19:48, Oleksandr Tyshchenko wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
> #include "hvm/save.h"
> #include "memory.h"
>
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x0014
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0015
So
On 11.10.2021 20:05, Andrew Cooper wrote:
> The is_pv_32bit_vcpu() conditionals hide four lfences, with two taken on any
> individual path through the function. There is very little code common
> between compat and native, and context-dependent conditionals predict very
> badly for a period of tim
On 12.10.2021 10:41, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>>
>> On 11.10.2021 19:11, Bertrand Marquis wrote:
On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
On Mon, Oct 11, 2021 at 02:16:19PM +, Bertrand Marquis wrote:
>> On 11 Oc
Hi Stefano,
On 12/10/2021 02:31, Stefano Stabellini wrote:
On Mon, 11 Oct 2021, Julien Grall wrote:
Hi Stefano,
On 11/10/2021 22:24, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 840728d6c0..076b827bdd 100644
--- a/xen/arch/arm/efi/efi-
On 12.10.2021 11:05, Luca Fancellu wrote:
>> On 12 Oct 2021, at 09:45, Jan Beulich wrote:
>> On 11.10.2021 20:15, Luca Fancellu wrote:
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -166,6 +166,13 @@ static void __init PrintErr(const CHAR16 *s)
>>> StdErr->OutputString(
On 12.10.21 12:32, Jan Beulich wrote:
> On 12.10.2021 10:41, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>>>
>>> On 11.10.2021 19:11, Bertrand Marquis wrote:
> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
> On Mon, Oct 11, 2021 at 02:16:19P
Hi Jan,
> On 12 Oct 2021, at 10:32, Jan Beulich wrote:
>
> On 12.10.2021 10:41, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>>>
>>> On 11.10.2021 19:11, Bertrand Marquis wrote:
> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
> On Mon, Oct
On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
> On 12.10.21 12:32, Jan Beulich wrote:
>> On 12.10.2021 10:41, Bertrand Marquis wrote:
On 12 Oct 2021, at 09:29, Jan Beulich wrote:
On 11.10.2021 19:11, Bertrand Marquis wrote:
>> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
>
On 12.10.2021 11:40, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 12 Oct 2021, at 10:32, Jan Beulich wrote:
>>
>> On 12.10.2021 10:41, Bertrand Marquis wrote:
>>> Hi Jan,
>>>
On 12 Oct 2021, at 09:29, Jan Beulich wrote:
On 11.10.2021 19:11, Bertrand Marquis wrote:
>> On 11 Oct 20
On 12.10.21 13:01, Jan Beulich wrote:
> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
>> On 12.10.21 12:32, Jan Beulich wrote:
>>> On 12.10.2021 10:41, Bertrand Marquis wrote:
> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
> On 11.10.2021 19:11, Bertrand Marquis wrote:
>>> On 1
flight 165469 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206
Tests which are faili
On 12.10.2021 12:06, Oleksandr Andrushchenko wrote:
> On 12.10.21 13:01, Jan Beulich wrote:
>> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
>>> On 12.10.21 12:32, Jan Beulich wrote:
The minimal thing I'd suggest (or maybe you're doing this already)
would be to expose such BARs to t
Hi Roger,
On 11.10.2021 11:27, Roger Pau Monné wrote:
> On Wed, Oct 06, 2021 at 06:40:33PM +0100, Rahul Singh wrote:
>> Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
>> Reject the use of this new flag for x86 as VPCI is not supported for
>> DOMU guests for x86.
>
> I don't lik
Hi Jan,
> On 12 Oct 2021, at 11:20, Jan Beulich wrote:
>
> On 12.10.2021 12:06, Oleksandr Andrushchenko wrote:
>> On 12.10.21 13:01, Jan Beulich wrote:
>>> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
On 12.10.21 12:32, Jan Beulich wrote:
> The minimal thing I'd suggest (or maybe
On 12.10.2021 12:41, Bertrand Marquis wrote:
> So there is no comment remaining on this patch ?
No, but the comments weren't on the patch anyway, but on a question
raised in the course of the discussion.
> Would it possible to get an ack on it ?
No, as I can't ack this patch: I'm not a maintaine
On 12.10.21 12:24, Jan Beulich wrote:
Hi Jan
Thank you for thorough review.
On 11.10.2021 19:48, Oleksandr Tyshchenko wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@
#include "hvm/save.h"
#include "memory.h"
-#define XEN_DOMCTL_INTERFACE_V
On 12.10.2021 13:28, Oleksandr wrote:
> On 12.10.21 12:24, Jan Beulich wrote:
>> On 11.10.2021 19:48, Oleksandr Tyshchenko wrote:
>>> @@ -150,6 +150,7 @@ struct xen_domctl_getdomaininfo {
>>> uint32_t ssidref;
>>> xen_domain_handle_t handle;
>>> uint32_t cpupool;
>>> +uint8_t
flight 165473 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Andrew,
On 20/09/2021 18:25, Andrew Cooper wrote:
The feature is x86 and pv-dom0 specific, and each architecture's main trace.h
files are empty. Don't force all new architectures to create an empty file.
While moving the declaration of tb_init_done, change from int to bool.
Signed-off-by:
On Tue, Oct 12, 2021 at 2:09 AM Josef Johansson wrote:
>
> On 10/11/21 21:34, Josef Johansson wrote:
> > On 10/11/21 20:47, Josef Johansson wrote:
> >> More can be read over at freedesktop:
> >> https://gitlab.freedesktop.org/drm/amd/-/issues/1715
Hi, Josef,
If you compare
commit fcacdfbef5a1633
On 12.10.21 14:49, Jan Beulich wrote:
Hi Jan
On 12.10.2021 13:28, Oleksandr wrote:
On 12.10.21 12:24, Jan Beulich wrote:
On 11.10.2021 19:48, Oleksandr Tyshchenko wrote:
@@ -150,6 +150,7 @@ struct xen_domctl_getdomaininfo {
uint32_t ssidref;
xen_domain_handle_t handle;
On 12.10.2021 15:18, Oleksandr wrote:
> On 12.10.21 14:49, Jan Beulich wrote:
>> On 12.10.2021 13:28, Oleksandr wrote:
>>> On 12.10.21 12:24, Jan Beulich wrote:
On 11.10.2021 19:48, Oleksandr Tyshchenko wrote:
> @@ -150,6 +150,7 @@ struct xen_domctl_getdomaininfo {
>uint32_t ss
All these handlers are regular device interrupt handlers, so they already
went through the proper entry code which handles this correctly.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Boris Ostrovsky
Cc: x...@kernel.org
Cc: xen-devel@lists.xenproject.org
---
arc
On 10/12/21 15:07, Jason Andryuk wrote:
> On Tue, Oct 12, 2021 at 2:09 AM Josef Johansson wrote:
>> On 10/11/21 21:34, Josef Johansson wrote:
>>> On 10/11/21 20:47, Josef Johansson wrote:
More can be read over at freedesktop:
https://gitlab.freedesktop.org/drm/amd/-/issues/1715
> Hi, Jos
flight 165475 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165475/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Set some limits for xenstored in order to avoid it being killed by
OOM killer, or to run out of file descriptors.
Changes in V6:
- start daemon directly via prlimit
Changes in V5:
- respect /proc/sys/fs/nr_open (Ian Jackson)
Changes in V4:
- add comments
- switch to configure open file descripto
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoided.
Set /proc/$pid/oom_score_adj (if available) per default to -500 (this
translates to 50% of dom0 memory size) in order to allow xenstored to
use lar
Add a configuration item for the maximum number of open file
descriptors xenstored should be allowed to have.
The default should be "unlimited" in order not to restrict xenstored
in the number of domains it can support, but unfortunately the kernel
is normally limiting the maximum value via /proc/
Juergen Gross writes ("[PATCH v6 2/2] tools/xenstore: set open file descriptor
limit for xenstored"):
> Add a configuration item for the maximum number of open file
> descriptors xenstored should be allowed to have.
>
> The default should be "unlimited" in order not to restrict xenstored
> in the
Hi,
Would you be so kind to look at my patches, it would help me to
know exactly whether I'm moving correctly and whether I've chosen
the right path?
Thanks!
Best regards,
Roman
пн, 4 окт. 2021 г. в 12:54, Roman Skakun :
>
> From: Roman Skakun
>
> At the moment, Dom0 can't distinguish which dev
On 12/10/2021 15:11, Roman Skakun wrote:
Hi,
Hi Roman,
Would you be so kind to look at my patches, it would help me to
know exactly whether I'm moving correctly and whether I've chosen
the right path?
This is in my queue to review. At the moment, I am prioritizing work
targeting 4.16. U
Understood.
Thank you!
вт, 12 окт. 2021 г. в 17:20, Julien Grall :
>
>
>
> On 12/10/2021 15:11, Roman Skakun wrote:
> > Hi,
>
> Hi Roman,
>
> > Would you be so kind to look at my patches, it would help me to
> > know exactly whether I'm moving correctly and whether I've chosen
> > the right path?
On 12.10.21 15:33, Thomas Gleixner wrote:
All these handlers are regular device interrupt handlers, so they already
went through the proper entry code which handles this correctly.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Boris Ostrovsky
Cc: x...@kernel.org
On Tue, Oct 12, 2021 at 10:13:23AM +0200, Michal Orzel wrote:
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index e356b2106d..2a0234ec16 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -622,6 +623,9 @@ int libxl__domai
Hi Rahul,
On 06/10/2021 18:40, Rahul Singh wrote:
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c9277b5c6d..91d614b37e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -2,6 +2,7 @@
#define __ASM_DOMAIN_H__
#include
+#includ
Hi Julien,
> On 12 Oct 2021, at 15:32, Julien Grall wrote:
>
> Hi Rahul,
>
> On 06/10/2021 18:40, Rahul Singh wrote:
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index c9277b5c6d..91d614b37e 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-
flight 165474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165474/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ba4ae92234b1985a89b3abed221d825b8d9ef9e2
baseline version:
ovmf 19ee56c4b33faa3307889
We don't use ifdefs in the main code. Actually document this.
Signed-off-by: Ian Jackson
---
tools/libs/light/CODING_STYLE | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/libs/light/CODING_STYLE b/tools/libs/light/CODING_STYLE
index 3d572f6925..c2342c9d3b 100644
--- a/tool
Bertrand Marquis writes ("Re: [PATCH v5 01/11] xen/arm:
xc_domain_ioport_permission(..) not supported on ARM."):
> So there is no comment remaining on this patch ?
I have been following this thread. I think I have a notion of why
this is needed but I'm not 100% clear on it. The commit message s
Rahul Singh writes ("[PATCH v5 10/11] arm/libxl: Emulated PCI device tree node
in libxl"):
> libxl will create an emulated PCI device tree node in the device tree to
> enable the guest OS to discover the virtual PCI during guest boot.
> Emulated PCI device tree node will only be created when there
On 11/10/2021 13:41, Bertrand Marquis wrote:
Hi Jan,
Hi Bertrand,
As Rahul is on leave, I will answer you and make the changes needed.
On 7 Oct 2021, at 14:43, Jan Beulich wrote:
Independent of this - is bare metal Arm enforcing this same
alignment restriction (unconditionally)? Iirc on x8
On Tue, Oct 12, 2021 at 03:52:26PM +0100, Ian Jackson wrote:
> We don't use ifdefs in the main code. Actually document this.
>
> Signed-off-by: Ian Jackson
> ---
> tools/libs/light/CODING_STYLE | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/libs/light/CODING_STYLE b
On 12.10.21 16:52, Ian Jackson wrote:
We don't use ifdefs in the main code. Actually document this.
Signed-off-by: Ian Jackson
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Stefano Stabellini writes ("Re: [PATCH V6 2/2] libxl/arm: Add handling of
extended regions for DomU"):
> On Mon, 11 Oct 2021, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > The extended region (safe range) is a region of guest physical
> > address space which is unused and co
Oleksandr Tyshchenko writes ("[PATCH V6 1/2] xen/arm: Introduce gpaddr_bits
field to struct xen_domctl_getdomaininfo"):
> From: Oleksandr Tyshchenko
>
> We need to pass info about maximum supported guest physical
> address space size to the toolstack on Arm in order to properly
> calculate the b
flight 165470 linux-linus real [real]
flight 165478 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165470/
http://logs.test-lab.xenproject.org/osstest/logs/165478/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 10/12/21 15:33, Josef Johansson wrote:
> On 10/12/21 15:07, Jason Andryuk wrote:
>> On Tue, Oct 12, 2021 at 2:09 AM Josef Johansson wrote:
>>> On 10/11/21 21:34, Josef Johansson wrote:
On 10/11/21 20:47, Josef Johansson wrote:
> More can be read over at freedesktop:
> https://gitla
Stefano Stabellini writes ("ARM series with tools patches for 4.16"):
> I am writing this email as a summary of the outstanding ARM series
> targeting 4.16 that we are aiming to complete by Oct 15.
Thanks. This is really helpful.
> There has been a lot of traffic on the mailing list and in a few
On 11.10.21 20:48, Oleksandr Tyshchenko wrote:
Hi Ian, Stefano
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain
Hi Bertrand,
On 11/10/2021 15:11, Bertrand Marquis wrote:
On 11/10/2021 10:00, Michal Orzel wrote:
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps(currently only for ARM).
The current status is that the PMU registers are not
Oleksandr writes ("Re: [PATCH V6 2/2] libxl/arm: Add handling of extended
regions for DomU"):
> On 11.10.21 20:48, Oleksandr Tyshchenko wrote:
> Hi Ian, Stefano
> > +LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"\n",
>
> If this appears to be the last version, may I please ask to
Hi Michal,
On 12/10/2021 09:13, Michal Orzel wrote:
diff --git a/SUPPORT.md b/SUPPORT.md
index 317392d8f3..2f1f60c49a 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -256,6 +256,15 @@ from dom0.
Status, x86: Tech Preview
+### vPMU support
There is already a section vPMU that is meant t
On 12.10.21 18:32, Ian Jackson wrote:
Hi Ian
Oleksandr writes ("Re: [PATCH V6 2/2] libxl/arm: Add handling of extended regions
for DomU"):
On 11.10.21 20:48, Oleksandr Tyshchenko wrote:
Hi Ian, Stefano
+LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"\n",
If this appears to
flight 165471 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165471/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 165467
test-armhf-armhf-xl-rtds
Hi Jan,
On 10/12/21 1:40 AM, Jan Beulich wrote:
> On 12.10.2021 09:24, Dongli Zhang wrote:
>> The guest may access the pv vcpu_time_info immediately after
>> VCPUOP_register_vcpu_info. This is to borrow the idea of
>> VCPUOP_register_vcpu_time_memory_area, where the
>> force_update_vcpu_system_tim
On 12.10.21 18:15, Ian Jackson wrote:
Hi Ian
Oleksandr Tyshchenko writes ("[PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to
struct xen_domctl_getdomaininfo"):
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest physical
address space size to the toolstack o
On 12.10.2021 17:43, Dongli Zhang wrote:
> Hi Jan,
>
> On 10/12/21 1:40 AM, Jan Beulich wrote:
>> On 12.10.2021 09:24, Dongli Zhang wrote:
>>> The guest may access the pv vcpu_time_info immediately after
>>> VCPUOP_register_vcpu_info. This is to borrow the idea of
>>> VCPUOP_register_vcpu_time_mem
Hi Juergen,
On 10/12/21 1:47 AM, Juergen Gross wrote:
> On 12.10.21 09:24, Dongli Zhang wrote:
>> When the kdump/kexec is enabled at HVM VM side, to panic kernel will trap
>> to xen side with reason=soft_reset. As a result, the xen will reboot the VM
>> with the kdump kernel.
>>
>> Unfortunately,
Hi Oleksandr,
On 11/10/2021 18:48, Oleksandr Tyshchenko wrote:
---
tools/libs/light/libxl_arm.c | 76 ---
xen/include/public/arch-arm.h | 2 ++
2 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/
Hi Julien,
> On 12 Oct 2021, at 16:04, Julien Grall wrote:
>
> On 11/10/2021 13:41, Bertrand Marquis wrote:
>> Hi Jan,
>
> Hi Bertrand,
>
>> As Rahul is on leave, I will answer you and make the changes needed.
>>> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
>>> Independent of this - is bare m
Hi Jan,
On 10/12/21 8:49 AM, Jan Beulich wrote:
> On 12.10.2021 17:43, Dongli Zhang wrote:
>> Hi Jan,
>>
>> On 10/12/21 1:40 AM, Jan Beulich wrote:
>>> On 12.10.2021 09:24, Dongli Zhang wrote:
The guest may access the pv vcpu_time_info immediately after
VCPUOP_register_vcpu_info. This is
Hi Ian,
> On 12 Oct 2021, at 15:53, Ian Jackson wrote:
>
> Bertrand Marquis writes ("Re: [PATCH v5 01/11] xen/arm:
> xc_domain_ioport_permission(..) not supported on ARM."):
>> So there is no comment remaining on this patch ?
>
> I have been following this thread. I think I have a notion of w
Oleksandr writes ("Re: [PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to
struct xen_domctl_getdomaininfo"):
> > Oleksandr Tyshchenko writes ("[PATCH V6 1/2] xen/arm: Introduce gpaddr_bits
> > field to struct xen_domctl_getdomaininfo"):
> > You say "to the toolstack", but you are exposing thi
On 12/10/2021 17:12, Bertrand Marquis wrote:
Hi Julien,
On 12 Oct 2021, at 16:04, Julien Grall wrote:
On 11/10/2021 13:41, Bertrand Marquis wrote:
Hi Jan,
Hi Bertrand,
As Rahul is on leave, I will answer you and make the changes needed.
On 7 Oct 2021, at 14:43, Jan Beulich wrote:
In
Bertrand Marquis writes ("Re: [PATCH v5 01/11] xen/arm:
xc_domain_ioport_permission(..) not supported on ARM."):
> I can add something in the commit message about the fact that we improve
> performance and prevent to do a call that is and will not be supported in Xen.
Thanks but I'm afraid I don'
On 10/12/21 3:24 AM, Dongli Zhang wrote:
The sched_clock() can be used very early since upstream
commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
with upstream commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock
time from 0"), kdump kernel in Xen HVM guest may
On 12.10.21 19:05, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 11/10/2021 18:48, Oleksandr Tyshchenko wrote:
---
tools/libs/light/libxl_arm.c | 76
---
xen/include/public/arch-arm.h | 2 ++
2 files changed, 73 insertions(+), 5 deletions
Hi Julien,
> On 12 Oct 2021, at 17:20, Julien Grall wrote:
>
>
>
> On 12/10/2021 17:12, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 12 Oct 2021, at 16:04, Julien Grall wrote:
>>>
>>> On 11/10/2021 13:41, Bertrand Marquis wrote:
Hi Jan,
>>>
>>> Hi Bertrand,
>>>
As Rahul is on lea
On 12.10.21 19:18, Ian Jackson wrote:
Hi Ian
Oleksandr writes ("Re: [PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to struct
xen_domctl_getdomaininfo"):
Oleksandr Tyshchenko writes ("[PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to
struct xen_domctl_getdomaininfo"):
You say "to
flight 165479 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165479/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Oleksandr writes ("Re: [PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to
struct xen_domctl_getdomaininfo"):
> Please note, it is going to be a new version of this patch based on
> today's discussion with Jan.
OK. Please retain my R-b if you don't change any of the tools parts.
Ian.
On 12.10.21 21:07, Ian Jackson wrote:
Hi Ian
Oleksandr writes ("Re: [PATCH V6 1/2] xen/arm: Introduce gpaddr_bits field to struct
xen_domctl_getdomaininfo"):
Please note, it is going to be a new version of this patch based on
today's discussion with Jan.
OK. Please retain my R-b if you do
On Tue, 12 Oct 2021, Ian Jackson wrote:
> Bertrand Marquis writes ("Re: [PATCH v5 01/11] xen/arm:
> xc_domain_ioport_permission(..) not supported on ARM."):
> > I can add something in the commit message about the fact that we improve
> > performance and prevent to do a call that is and will not be
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest physical
address space size to the toolstack on Arm in order to properly
calculate the base and size of the extended region (safe range)
for the guest. The extended region is unused address space which
could be safely u
Hi Oleksandr,
On 12/10/2021 18:42, Oleksandr wrote:
On 12.10.21 19:05, Julien Grall wrote:
On 11/10/2021 18:48, Oleksandr Tyshchenko wrote:
---
tools/libs/light/libxl_arm.c | 76
---
xen/include/public/arch-arm.h | 2 ++
2 files changed, 73 inser
On Tue, 12 Oct 2021, Jan Beulich wrote:
> On 11.10.2021 20:18, Stefano Stabellini wrote:
> > On Mon, 11 Oct 2021, Jan Beulich wrote:
> >> On 11.10.2021 15:34, Bertrand Marquis wrote:
> On 11 Oct 2021, at 14:09, Jan Beulich wrote:
> On 11.10.2021 14:41, Bertrand Marquis wrote:
> > But
On 13.10.21 00:22, Julien Grall wrote:
Hi Oleksandr,
Hi Julien, Ian.
Julien, thank you for the detailed answer, I will analyze it tomorrow.
Ian, I think, there is no reason in providing git branch with the acks
folded in + my minor fix for the debug message as it was discussed
before, it
On Mon, 11 Oct 2021, Roger Pau Monné wrote:
> On Wed, Oct 06, 2021 at 06:40:33PM +0100, Rahul Singh wrote:
> > Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
> > Reject the use of this new flag for x86 as VPCI is not supported for
> > DOMU guests for x86.
>
> I don't like this a
1 - 100 of 125 matches
Mail list logo
