On 25.01.2021 18:30, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd
> compressed kernels"):
>> On 25.01.2021 17:17, Ian Jackson wrote:
>>> I think we had concluded not to print a warning ?
>>
>> Yes. Even in the projected new form of using the construct I
On 25.01.2021 17:31, Jan Beulich wrote:
> On 21.01.2021 22:27, Andrew Cooper wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -1068,11 +1068,35 @@ static unsigned int resource_max_frames(const struct
>> domain *d,
>> case XENMEM_resource_grant_table:
>> return
flight 158616 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 158387
Tests which are
On 25.01.21 18:26, Andrew Cooper wrote:
On 25/01/2021 14:00, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..82948251f57b 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,14 @@
flight 158613 qemu-mainline real [real]
flight 158621 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158613/
http://logs.test-lab.xenproject.org/osstest/logs/158621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
> Thanks for the response!
>
> On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini
> wrote:
> + xen-devel, Roman,
>
>
> On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
> > Hi Stefano,
> > I'm Jukka Kaartinen a SW developer working
Simple test cases for the four Argo operations, register, unregister,
sendv and notify exercised with a single test domain.
Add infrastructure to access Argo: a 5-argument hypercall, number 39.
Signed-off-by: Christopher Clark
---
arch/x86/hypercall_page.S| 2 +-
On 26.01.21 01:20, Julien Grall wrote:
Hi Julien, Stefano
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini wrote:
Julien,
Hi,
This seems to be an arm randconfig failure:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/246632953
On 26.01.21 01:13, Julien Grall wrote:
Hi,
Hi Julien
On Mon, 25 Jan 2021 at 19:09, Oleksandr Tyshchenko wrote:
***
Please note, this patch depends on the following which is
on review:
https://patchwork.kernel.org/patch/11816689/
The effort (to get it upstreamed) was paused because of
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini wrote:
>
> Julien,
Hi,
>
> This seems to be an arm randconfig failure:
>
> https://gitlab.com/xen-project/patchew/xen/-/pipelines/246632953
> https://gitlab.com/xen-project/patchew/xen/-/jobs/985455044
Thanks! The error is:
#'target_mem_ref'
flight 158618 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158618/
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
Hi,
On Mon, 25 Jan 2021 at 19:09, Oleksandr Tyshchenko wrote:
> ***
> Please note, this patch depends on the following which is
> on review:
> https://patchwork.kernel.org/patch/11816689/
> The effort (to get it upstreamed) was paused because of
> the security issue around that code (XSA-348).
>
flight 158611 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158611/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.
1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to enable EXPERT to get a
Add an "(EXPERT)" tag to the one-line description of Kconfig options
that depend on EXPERT.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@citrix.com
CC: i...@xenproject.org
CC: jbeul...@suse.com
CC: jul...@xen.org
CC: w...@xen.org
---
Changes in v4:
- new
Hi all,
A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.
1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to enable EXPERT to
On Mon, 25 Jan 2021, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 23 Jan 2021, at 02:19, Stefano Stabellini wrote:
> >
> > A recent thread [1] has exposed a couple of issues with our current way
> > of handling EXPERT.
> >
> > 1) It is not obvious that "Configure standard Xen features
On Mon, 25 Jan 2021, Jan Beulich wrote:
> On 23.01.2021 03:19, Stefano Stabellini wrote:
> > --- a/xen/Kconfig
> > +++ b/xen/Kconfig
> > @@ -34,8 +34,15 @@ config DEFCONFIG_LIST
> > option defconfig_list
> > default ARCH_DEFCONFIG
> >
> > +config UNSUPPORTED
> > + bool "Configure
Julien,
This seems to be an arm randconfig failure:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/246632953
https://gitlab.com/xen-project/patchew/xen/-/jobs/985455044
On Mon, 25 Jan 2021, no-re...@patchew.org wrote:
> Hi,
>
> Patchew automatically ran gitlab-ci pipeline with this
On Mon, 25 Jan 2021, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch adds basic IOREQ/DM support on Arm. The subsequent
> patches will improve functionality and add remaining bits.
>
> The IOREQ/DM features are supposed to be built with IOREQ_SERVER
> option enabled, which is
On 08/10/2020 19:57, Paul Durrant wrote:
> From: Paul Durrant
>
> Paul Durrant (11):
> docs / include: introduce a new framework for 'domain context' records
> xen: introduce implementation of save/restore of 'domain context'
> xen/common/domctl: introduce XEN_DOMCTL_get/set_domain_context
On 08/10/2020 19:57, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch adds the necessary code to save a REC_TYPE_DOMAIN_CONTEXT record,
> and stop saving the now obsolete REC_TYPE_SHARED_INFO and REC_TYPE_TSC_INFO
> records for PV guests.
>
> Signed-off-by: Paul Durrant
Looks broadly ok.
flight 158614 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158614/
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
On 08/10/2020 19:57, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch adds the necessary code to accept a v4 stream, and to recognise and
> restore a REC_TYPE_DOMAIN_CONTEXT record.
>
> Signed-off-by: Paul Durrant
Somewhere within this needs to be logic to reject the forbidden records
in
On 08/10/2020 19:57, Paul Durrant wrote:
> @@ -476,6 +484,14 @@ class VerifyLibxc(VerifyBase):
> raise RecordError("Record length %u, expected multiple of %u" %
>(contentsz, sz))
>
> +def verify_record_domain_context(self, content):
> +"""
On 08/10/2020 19:57, Paul Durrant wrote:
> diff --git a/docs/specs/libxc-migration-stream.pandoc
> b/docs/specs/libxc-migration-stream.pandoc
> index 8aeab3b11b..aa6fe284f3 100644
> --- a/docs/specs/libxc-migration-stream.pandoc
> +++ b/docs/specs/libxc-migration-stream.pandoc
> @@ -127,7 +127,7
On 08/10/2020 19:57, Paul Durrant wrote:
> From: Paul Durrant
>
> The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have
> sections explaining what they are but their values are not defined. Indeed
> their values are defined as "Reserved for future mandatory records."
>
>
On 08/10/2020 19:57, Paul Durrant wrote:
> +The record body contains the following fields:
> +
> +| Field | Description |
> +|---|---|
> +| `mode`| 0x: Default (emulate if necessary)
From: Julien Grall
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality and add remaining bits.
The IOREQ/DM features are supposed to be built with IOREQ_SERVER
option enabled, which is disabled by default on Arm for now.
Please note, the "PIO
From: Oleksandr Tyshchenko
This patch adds remaining bits needed for the IOREQ support on Arm.
Besides just calling vcpu_ioreq_handle_completion() we need to handle
it's return value to make sure that all the vCPU works are done before
we return to the guest (the vcpu_ioreq_handle_completion()
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level of a one of a domain's IRQ lines.
We can't reuse the
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remove the existing
mapping before inserting the new mapping. Instead, this is done
implicitely by
From: Oleksandr Tyshchenko
In the ideal world we would never get an undefined behavior when
propagating the sign bit since that bit can only be set for access
size smaller than the register size (i.e byte/half-word for aarch32,
byte/half-word/word for aarch64).
In the real world we need to care
On 08/10/2020 19:57, Paul Durrant wrote:
> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> index c4be9f570c..bccbaadd0b 100644
> --- a/xen/include/public/save.h
> +++ b/xen/include/public/save.h
> @@ -58,6 +59,16 @@ struct domain_context_start {
> uint32_t xen_major,
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as a part of new
struct vcpu_io and drop duplicating "io" prefixes. Also move
enum hvm_io_completion to xen/sched.h and remove "hvm" prefixes.
This patch
From: Julien Grall
As x86 implementation of XENMEM_resource_ioreq_server can be
re-used on Arm later on, this patch makes it common and removes
arch_acquire_resource (and the corresponding option) as unneeded.
Also re-order #include-s alphabetically.
This support is going to be used on Arm to
From: Oleksandr Tyshchenko
This patch implements reference counting of foreign entries in
in set_foreign_p2m_entry() on Arm. This is a mandatory action if
we want to run emulator (IOREQ server) in other than dom0 domain,
as we can't trust it to do the right thing if it is not running
in dom0. So
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for both.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
Reviewed-by: Stefano Stabellini
[On
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
moves the IOREQ related dm-op handling to the common code.
The idea is to have the top level dm-op handling arch-specific
and call into ioreq_server_dm_op() for otherwise unhandled ops.
Pros:
- More natural than
From: Oleksandr Tyshchenko
This patch introduces a helper the main purpose of which is to check
if a domain is using IOREQ server(s).
On Arm the current benefit is to avoid calling vcpu_ioreq_handle_completion()
(which implies iterating over all possible IOREQ servers anyway)
on every return in
From: Oleksandr Tyshchenko
This patch removes "hvm" prefixes and infixes from IOREQ related
function names in the common code and performs a renaming where
appropriate according to the more consistent new naming scheme:
- IOREQ server functions should start with "ioreq_server_"
- IOREQ functions
From: Oleksandr Tyshchenko
As the IOREQ is a common feature now and we also need to
invalidate qemu/demu mapcache on Arm when the required condition
occurs this patch moves this function to the common code
(and remames it to ioreq_signal_mapcache_invalidate).
This patch also moves per-domain
From: Oleksandr Tyshchenko
The cmpxchg() in ioreq_send_buffered() operates on memory shared
with the emulator domain (and the target domain if the legacy
interface is used).
In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
The point
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this struct will be used
on Arm as is. Move it to common struct domain. This also
significantly reduces the layering violation in the common code
(*arch.hvm* usage).
We don't move ioreq_gfn since it is not used in the common code
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
Reviewed-by: Paul Durrant
Reviewed-by: Alex
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared IOREQ support to the common code
(the code movement is verbatim copy).
The "legacy" mechanism of mapping magic pages for the IOREQ servers
remains x86 specific and not exposed to
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
with "ioreq".
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the current series
(it will be implemented when we add support for vPCI), technically
the
From: Oleksandr Tyshchenko
The IOREQ is about to be common feature and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on Arm (we already have a try_handle_mmio()).
In order not to rename the function (which is used for a varying
set of
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy
for a code movement in subsequent patch.
This patch mostly introduces specific hooks to
From: Oleksandr Tyshchenko
This patch continues to make some preparation to x86/hvm/ioreq.c
before moving to the common code.
Add IOREQ_STATUS_* #define-s and update candidates for moving
since X86EMUL_* shouldn't be exposed to the common code in
that form.
This support is going to be used on
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC-V4 series at [2]-[6].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement
flight 158609 linux-5.4 real [real]
flight 158615 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158609/
http://logs.test-lab.xenproject.org/osstest/logs/158615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On 21-01-25 11:22:08, Jan Beulich wrote:
> On 22.01.2021 20:52, Boris Ostrovsky wrote:
> > On 1/22/21 7:51 AM, Jan Beulich wrote:
> >> On 20.01.2021 23:49, Boris Ostrovsky wrote:
> >>> +
> >>> +/*
> >>> + * Accesses to unimplemented MSRs as part of emulation of
> >>> instructions
> >>> +
On 08/10/2020 19:57, Paul Durrant wrote:
> diff --git a/xen/common/save.c b/xen/common/save.c
> new file mode 100644
> index 00..9287b20198
> --- /dev/null
> +++ b/xen/common/save.c
> @@ -0,0 +1,339 @@
>
> +static int load_start(struct domain *d, struct domain_ctxt_state *c)
> +{
> +
On Mon, 25 Jan 2021, Rahul Singh wrote:
> Hello Julien,
>
> > On 23 Jan 2021, at 11:55 am, Julien Grall wrote:
> >
> > Hi Rahul
> >
> > On 22/01/2021 11:37, Rahul Singh wrote:
> >> Add support for ARM architected SMMUv3 implementation. It is based on
> >> the Linux SMMUv3 driver.
> >> Driver
On 19/10/2020 14:46, Jan Beulich wrote:
> On 08.10.2020 20:57, Paul Durrant wrote:
>> --- /dev/null
>> +++ b/xen/include/public/save.h
>> @@ -0,0 +1,66 @@
>> +/*
>> + * save.h
>> + *
>> + * Structure definitions for common PV/HVM domain state that is held by Xen.
>> + *
>> + * Copyright Amazon.com
On 08/10/2020 19:57, Paul Durrant wrote:
> diff --git a/xen/include/public/save.h b/xen/include/public/save.h
> new file mode 100644
> index 00..c4be9f570c
> --- /dev/null
> +++ b/xen/include/public/save.h
> @@ -0,0 +1,66 @@
> +/*
> + * save.h
> + *
> + * Structure definitions for common
> -Original Message-
> From: Igor Druzhinin
> Sent: 12 January 2021 04:17
> To: xen-devel@lists.xenproject.org
> Cc: i...@xenproject.org; w...@xen.org; andrew.coop...@citrix.com;
> george.dun...@citrix.com;
> jbeul...@suse.com; jul...@xen.org; sstabell...@kernel.org;
>
On 20/01/2021 08:06, Jan Beulich wrote:
> On 19.01.2021 19:09, Andrew Cooper wrote:
>> On 19/01/2021 16:48, Jan Beulich wrote:
>>> On 19.01.2021 14:02, Andrew Cooper wrote:
This code has been copied in 3 places, but it is problematic.
All cases will hit a BUG() later in domain
At 12:07 +0100 on 25 Jan (1611576438), Jan Beulich wrote:
> 15 apparently once used to be the last valid type to request a callback
> for, and the dimension of the respective array. The arrays meanwhile are
> larger than this (in a benign way, i.e. no caller ever sets a mask bit
> higher than 15),
On Mon, Jan 25, 2021 at 10:56:25AM +0100, Jan Beulich wrote:
> On 24.01.2021 05:47, Elliott Mitchell wrote:
> >
> > ---
> > Changes in v2:
> > - Include the obvious removal of the goto target. Always realize you're
> > at the wrong place when you press "send".
>
> Please could you also label
The quoted-reply part of this message may be going off into the weeds.
Feel free to ignore it, or parts of it, if you think you can make
progress without disabusing me of what I think are my
misunderstandings...
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed
On 25/01/2021 14:00, Juergen Gross wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4409306364dc..82948251f57b 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -583,6 +583,14 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
>
On 25/01/2021 15:08, Jan Beulich wrote:
> On 21.01.2021 22:27, Andrew Cooper wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -132,6 +132,48 @@ static void vcpu_info_reset(struct vcpu *v)
>> v->vcpu_info_mfn = INVALID_MFN;
>> }
>>
>> +static void
On 25.01.2021 17:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd
> compressed kernels"):
>> On 25.01.2021 15:53, Ian Jackson wrote:
>>> Well how about passing "true" for the fourth argument then ?
>>
>> That I did try intermediately, but didn't ever
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1068,11 +1068,35 @@ static unsigned int resource_max_frames(const struct
> domain *d,
> case XENMEM_resource_grant_table:
> return gnttab_resource_max_frames(d, id);
>
> +
I have a feeling we may be talking at cross purposes rather too much.
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed
kernels"):
> On 25.01.2021 15:53, Ian Jackson wrote:
> > Well how about passing "true" for the fourth argument then ?
>
> That I did try
On Fri, 2021-01-22 at 14:26 +, Julien Grall wrote:
> Hi Anders,
>
> On 22/01/2021 08:06, Anders Törnqvist wrote:
> > On 1/22/21 12:35 AM, Dario Faggioli wrote:
> > > On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
> > - booting with "sched=null vwfi=native" but not doing the IRQ
> >
On Fri, 2021-01-22 at 18:44 +0100, Anders Törnqvist wrote:
> Listing vcpus looks like this when the domain is running:
>
> xl vcpu-list
> Name ID VCPU CPU State Time(s)
> Affinity (Hard / Soft)
> Domain-0 0 0 0 r--
On 12/01/2021 04:17, Igor Druzhinin wrote:
> TLFS 7.8.1 stipulates that "a virtual processor index must be less than
> the maximum number of virtual processors per partition" that "can be obtained
> through CPUID leaf 0x4005". Furthermore, "Requirements for Implementing
> the Microsoft
On 25.01.2021 15:53, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd
> compressed kernels"):
>> On 25.01.2021 14:51, Ian Jackson wrote:
>>> I mean, the parts where you examine libzstd_PKG_ERRORS.
>>
>> The only thing I make use of is it being (non-)empty.
On 22/01/2021 15:33, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
>> From: Michał Leszczyński
> ...
>> +if ( signal(SIGINT, int_handler) == SIG_ERR )
>> +err(1, "Failed to register signal handler\n");
> How bad is it if this signal
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -132,6 +132,48 @@ static void vcpu_info_reset(struct vcpu *v)
> v->vcpu_info_mfn = INVALID_MFN;
> }
>
> +static void vmtrace_free_buffer(struct vcpu *v)
> +{
> +const struct domain *d
On 25/01/2021 11:03, Jan Beulich wrote:
> $(xlat-y) getting derived from $(headers-y) means its contents may
> change with changes to .config. The individual files $(xlat-y) refers
> to, otoh, may not change, and hence not trigger rebuilding of xlat.h.
> (Note that the issue was already present
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed
kernels"):
> On 25.01.2021 14:51, Ian Jackson wrote:
> > I mean, the parts where you examine libzstd_PKG_ERRORS.
>
> The only thing I make use of is it being (non-)empty. Do you
> really think that's a problem?
It's
flight 158607 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158607/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-migrupgrade 21 debian-fixup/dst_host fail pass in 158601
test-arm64-arm64-examine 8
On 25.01.2021 14:51, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd
> compressed kernels"):
>> On 25.01.2021 12:30, Ian Jackson wrote:
As far as configure.ac goes, I'm pretty sure there is a better (more
"standard") way of using
When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT
enabled as a Xen pv guest a warning is issued for each processor:
[5.964347] [ cut here ]
[5.968314] WARNING: CPU: 0 PID: 1 at
/home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660
Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed
kernels"):
> On 25.01.2021 12:30, Ian Jackson wrote:
> >> As far as configure.ac goes, I'm pretty sure there is a better (more
> >> "standard") way of using PKG_CHECK_MODULES().
> >
> > Yes, what you have done is
On 09.01.2021 17:14, Julien Grall wrote:
> On 09/01/2021 15:41, Julien Grall wrote:
>> On 05/01/2021 13:09, Jan Beulich wrote:
>>> The local domain's lock is needed for the port allocation, but for the
>>> remote side the per-channel lock is sufficient. The per-channel locks
>>> then need to be
Jan Beulich writes ("Re: [PATCH v2 3/5] libxenguest: "standardize" LZO kernel
decompression code"):
> On 25.01.2021 12:59, Ian Jackson wrote:
> > I don't mind throwing in the DOMPRINTF too.
>
> Am I fine to transliterate this into R-a-b?
Err, yes, sorry, should have been more explicit.
Ian.
On 25.01.2021 12:59, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 3/5] libxenguest: "standardize" LZO kernel
> decompression code"):
>> On Tue, Jan 19, 2021 at 04:16:35PM +0100, Jan Beulich wrote:
>>> Add a DOMPRINTF() other methods have, indicating success. To facilitate
>>> this,
On 25.01.2021 12:30, Ian Jackson wrote:
> Hi. Thanks for this. Firstly, RM hat: this is the tools half of zstd
> decompression support which I think is a blocker for the release. So
> I am going to waive the last posting date requirement. Therefore,
>
> Assuming it's committed this week:
>
>
Wei Liu writes ("Re: [PATCH v2 3/5] libxenguest: "standardize" LZO kernel
decompression code"):
> On Tue, Jan 19, 2021 at 04:16:35PM +0100, Jan Beulich wrote:
> > Add a DOMPRINTF() other methods have, indicating success. To facilitate
> > this, introduce an "outsize" local variable and update
flight 158608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158608/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 96a9acfc527964dc5ab7298862a0cd8aa5fffc6a
baseline version:
ovmf
On 22.01.2021 21:02, Tim Deegan wrote:
> At 17:31 +0100 on 22 Jan (1611336662), Jan Beulich wrote:
>> Because of this having been benign (due to none of the callback
>> tables specifying non-NULL entries there), wouldn't it make
>> sense to dimension the tables by SH_type_max_shadow + 1 only?
>>
Hi. Thanks for this. Firstly, RM hat: this is the tools half of zstd
decompression support which I think is a blocker for the release. So
I am going to waive the last posting date requirement. Therefore,
Assuming it's committed this week:
Release-Acked-by: Ian Jackson
Secondly, I think it
On 22.01.2021 21:02, Tim Deegan wrote:
> At 17:31 +0100 on 22 Jan (1611336662), Jan Beulich wrote:
>> On 22.01.2021 14:11, Tim Deegan wrote:
>>> At 16:10 +0100 on 14 Jan (1610640627), Jan Beulich wrote:
hash_{domain,vcpu}_foreach() have a use each of literal 15. It's not
clear to me what
15 apparently once used to be the last valid type to request a callback
for, and the dimension of the respective array. The arrays meanwhile are
larger than this (in a benign way, i.e. no caller ever sets a mask bit
higher than 15), dimensioned by SH_type_unused. Have the ASSERT()s
follow suit and
$(xlat-y) getting derived from $(headers-y) means its contents may
change with changes to .config. The individual files $(xlat-y) refers
to, otoh, may not change, and hence not trigger rebuilding of xlat.h.
(Note that the issue was already present before the commit referred to
below, but it was
On 25/01/2021 07:23, Juergen Gross wrote:
> There is a very unlikely use after free bug and a memory leak in
> live_update_start() of xenstore_control. Fix those.
>
> Coverity-Id: 1472399
> Fixes: 7f97193e6aa858 ("tools/xenstore: add live update command to
> xenstore-control")
> Signed-off-by:
flight 158606 qemu-mainline real [real]
flight 158612 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158606/
http://logs.test-lab.xenproject.org/osstest/logs/158612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
Hi Stefano,
> On 23 Jan 2021, at 02:19, Stefano Stabellini wrote:
>
> A recent thread [1] has exposed a couple of issues with our current way
> of handling EXPERT.
>
> 1) It is not obvious that "Configure standard Xen features (expert
> users)" is actually the famous EXPERT we keep talking
On 23.01.2021 14:22, Julien Grall wrote:
> On 13/01/2021 15:06, Oleksandr wrote:
>> On 12.01.21 13:58, Jan Beulich wrote:
>>> On 11.01.2021 09:23, Oleksandr wrote:
On 11.01.21 09:41, Jan Beulich wrote:
> If you could also provide your exact .config, I could see whether I
> can repro
On 22.01.2021 20:52, Boris Ostrovsky wrote:
> On 1/22/21 7:51 AM, Jan Beulich wrote:
>> On 20.01.2021 23:49, Boris Ostrovsky wrote:
>>> +
>>> +/*
>>> + * Accesses to unimplemented MSRs as part of emulation of instructions
>>> + * other than guest's RDMSR/WRMSR should never succeed.
>>>
On 25/01/2021 09:56, Jan Beulich wrote:
> On 24.01.2021 05:47, Elliott Mitchell wrote:
>> Previously p2m_pod_set_cache_target() would fall back to allocating 4KB
>> pages if 2MB pages ran out. This is counterproductive since it suggests
>> severe memory pressure and is likely a precursor to a
On 24.01.2021 11:35, scan-ad...@coverity.com wrote:
> *** CID 1472394: Concurrent data access violations (MISSING_LOCK)
> /xen/drivers/passthrough/x86/hvm.c: 1054 in pci_clean_dpci_irq()
> 1048 list_for_each_entry_safe ( digl, tmp, _dpci->digl_list,
> list )
> 1049 {
> 1050
On 24.01.2021 05:47, Elliott Mitchell wrote:
> Previously p2m_pod_set_cache_target() would fall back to allocating 4KB
> pages if 2MB pages ran out. This is counterproductive since it suggests
> severe memory pressure and is likely a precursor to a memory exhaustion
> panic. As such don't try to
On 23.01.2021 03:19, Stefano Stabellini wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -34,8 +34,15 @@ config DEFCONFIG_LIST
> option defconfig_list
> default ARCH_DEFCONFIG
>
> +config UNSUPPORTED
> + bool "Configure UNSUPPORTED features"
> + help
> + This option
1 - 100 of 105 matches
Mail list logo
