Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the CPU maps use-case.
In order to do this reserve 12bits o
Hello,
The following series implement support for read-locking a lock already
taken in write mode by the same CPU. Patch #1 add an atomic_and
operation to be used by patch #2 which implements the mentioned
behavior.
The series has been build tested on Arm by gitlab:
https://gitlab.com/xen-projec
To x86 and Arm. This performs an atomic AND operation against an
atomic_t variable with the provided mask.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
xen/include/asm-arm/arm32/atomic.h | 17 +
xen/include/asm-arm/arm64/atomic.h | 14 ++
xen/include/
On Sun, Feb 23, 2020 at 09:13:30PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/hvm/dom0_build.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 380412151b..ffbb2bd584 100644
> -
On 21.02.2020 18:39, Jan Beulich wrote:
> On 21.02.2020 09:30, Alexandru Stefan ISAILA wrote:
>> @@ -4835,6 +4836,26 @@ static int do_altp2m_op(
>> break;
>> }
>>
>> +case HVMOP_altp2m_set_visibility:
>> +{
>> +uint16_t idx = a.u.set_visibility.altp2m_idx;
>> +
On Mon, Feb 24, 2020 at 09:46:04AM +0100, Roger Pau Monné wrote:
> On Sun, Feb 23, 2020 at 09:13:30PM +, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/hvm/dom0_build.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/dom0_bu
Hi Roger,
The logic for Arm64 and Arm32 looks good to me. I just have one question
below.
On 24/02/2020 08:43, Roger Pau Monne wrote:
To x86 and Arm. This performs an atomic AND operation against an
atomic_t variable with the provided mask.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau
Hi Roger,
On 24/02/2020 08:44, Roger Pau Monne wrote:
Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the
On Mon, Feb 24, 2020 at 10:02:53AM +, Julien Grall wrote:
> Hi Roger,
>
> The logic for Arm64 and Arm32 looks good to me. I just have one question
> below.
>
> On 24/02/2020 08:43, Roger Pau Monne wrote:
> > To x86 and Arm. This performs an atomic AND operation against an
> > atomic_t variabl
Hi Wei,
On 24/02/2020 01:17, Wei Xu wrote:
Parse the ACPI SPCR table and initialize the 16550 compatible serial port
for ARM only. Currently we only support one UART on ARM. Some fields
which we do not care yet on ARM are ignored.
Signed-off-by: Wei Xu
Reviewed-by: Jan Beulich
I don't think
On Mon, Feb 24, 2020 at 10:05:39AM +, Julien Grall wrote:
> Hi Roger,
>
> On 24/02/2020 08:44, Roger Pau Monne wrote:
> > Allow a CPU already holding the lock in write mode to also lock it in
> > read mode. There's no harm in allowing read locking a rwlock that's
> > already owned by the calle
Hi,
On 24/02/2020 10:09, Roger Pau Monné wrote:
On Mon, Feb 24, 2020 at 10:02:53AM +, Julien Grall wrote:
Hi Roger,
The logic for Arm64 and Arm32 looks good to me. I just have one question
below.
On 24/02/2020 08:43, Roger Pau Monne wrote:
To x86 and Arm. This performs an atomic AND oper
On Mon, Feb 24, 2020 at 10:19:44AM +, Julien Grall wrote:
> Hi,
>
> On 24/02/2020 10:09, Roger Pau Monné wrote:
> > On Mon, Feb 24, 2020 at 10:02:53AM +, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > The logic for Arm64 and Arm32 looks good to me. I just have one question
> > > below.
>
Hi,
On 24/02/2020 10:23, Roger Pau Monné wrote:
On Mon, Feb 24, 2020 at 10:19:44AM +, Julien Grall wrote:
Hi,
On 24/02/2020 10:09, Roger Pau Monné wrote:
On Mon, Feb 24, 2020 at 10:02:53AM +, Julien Grall wrote:
Hi Roger,
The logic for Arm64 and Arm32 looks good to me. I just have o
On Mon, Feb 24, 2020 at 10:29:40AM +, Julien Grall wrote:
> Hi,
>
> On 24/02/2020 10:23, Roger Pau Monné wrote:
> > On Mon, Feb 24, 2020 at 10:19:44AM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 24/02/2020 10:09, Roger Pau Monné wrote:
> > > > On Mon, Feb 24, 2020 at 10:02:53AM +,
Add helpers to track when executing in #MC context. This is modeled
after the in_irq helpers.
Note that there are no users of in_mc() introduced by the change,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Move definition of mc_count to
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
-
Add helpers to track when running in #NMI context. This is modeled
after the in_irq helpers.
The SDM states that no #NMI can be delivered while handling a #NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the #NMI (a #MC
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
Introduced a bogus usage of the scratch cpumask: it was used in a
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe. Patc
Using scratch_cpumask in send_IPI_mask is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts whil
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nes
Hi Julien,
On 2020/2/24 18:09, Julien Grall wrote:
> Hi Wei,
>
> On 24/02/2020 01:17, Wei Xu wrote:
>> Parse the ACPI SPCR table and initialize the 16550 compatible serial port
>> for ARM only. Currently we only support one UART on ARM. Some fields
>> which we do not care yet on ARM are ignored.
On Tue, Feb 18, 2020 at 01:21:13PM +0100, Juergen Gross wrote:
> Some keyhandlers are calling process_pending_softirqs() while holding
> a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
> activate rcu calls which should not happen inside a rcu_read_lock().
It might be helpful
Check the serial port address space before checking the address.
Signed-off-by: Wei Xu
---
xen/drivers/char/ns16550.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index dc8ac4c..425e044 100644
--- a/xen/d
On Tue, Feb 18, 2020 at 01:21:14PM +0100, Juergen Gross wrote:
> Xen's RCU implementation relies on no softirq handling taking place
> while being in a RCU critical section. Add ASSERT()s in debug builds
> in order to catch any violations.
>
> For that purpose modify rcu_read_[un]lock() to use a d
On 24.02.20 12:25, Roger Pau Monné wrote:
On Tue, Feb 18, 2020 at 01:21:13PM +0100, Juergen Gross wrote:
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
activate rcu calls which should not happen inside a
On 24.02.20 12:31, Roger Pau Monné wrote:
On Tue, Feb 18, 2020 at 01:21:14PM +0100, Juergen Gross wrote:
Xen's RCU implementation relies on no softirq handling taking place
while being in a RCU critical section. Add ASSERT()s in debug builds
in order to catch any violations.
For that purpose mo
On Mon, Feb 24, 2020 at 12:44:48PM +0100, Jürgen Groß wrote:
> On 24.02.20 12:25, Roger Pau Monné wrote:
> > On Tue, Feb 18, 2020 at 01:21:13PM +0100, Juergen Gross wrote:
> > > Some keyhandlers are calling process_pending_softirqs() while holding
> > > a rcu_read_lock(). This is wrong, as process_
flight 147480 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
test-amd64-amd64-xl
On Fri, Feb 21, 2020 at 10:49:21AM -0800, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part
Hi Jan,
On 21/02/2020 16:59, Jan Beulich wrote:
On 01.02.2020 01:33, David Woodhouse wrote:
From: David Woodhouse
Remove a ternary operator that made my brain hurt.
Personally I'd prefer the code to stay as is, but if Andrew agrees
with this being an improvement, then I also wouldn't want t
The macros in xmalloc.h are a mix of using their type parameter directly, and
using typeof(). Switch uniformly to the latter so expressions can be used,
rather than only type names.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/xen/xmalloc.h
It turns out that these are unused, and we dup a type-dependent block of
zeros. Use xzalloc() instead.
Read/write MSRs are typically 0 to being with, and non-zero defaults would
need dealing with at suitable INIT/RESET points (e.g. arch_vcpu_regs_init).
Signed-off-by: Andrew Cooper
---
CC: Jan
On Mon, Feb 24, 2020 at 02:22:31PM +, Andrew Cooper wrote:
> It turns out that these are unused, and we dup a type-dependent block of
> zeros. Use xzalloc() instead.
>
> Read/write MSRs are typically 0 to being with, and non-zero defaults would
> need dealing with at suitable INIT/RESET point
On 24/02/2020 14:32, Roger Pau Monné wrote:
> On Mon, Feb 24, 2020 at 02:22:31PM +, Andrew Cooper wrote:
>> It turns out that these are unused, and we dup a type-dependent block of
>> zeros. Use xzalloc() instead.
>>
>> Read/write MSRs are typically 0 to being with, and non-zero defaults would
On Mon, Feb 24, 2020 at 02:22:19PM +, Andrew Cooper wrote:
> The macros in xmalloc.h are a mix of using their type parameter directly, and
> using typeof().
The only ones I could spot in the neighborhood are
xrealloc_flex_struct and xmemdup, which don't have a type parameter
but rather a point
flight 147482 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
On Fri, Feb 21, 2020 at 10:49:22AM -0800, Tamas K Lengyel wrote:
> Implement hypercall that allows a fork to shed all memory that got allocated
> for it during its execution and re-load its vCPU context from the parent VM.
> This allows the forked VM to reset into the same state the parent VM is in
On Fri, Feb 21, 2020 at 10:49:19AM -0800, Tamas K Lengyel wrote:
> During VM forking we'll copy the parent domain's parameters to the client,
> including the HAP shadow memory setting that is used for storing the domain's
> EPT. We'll copy this in the hypervisor instead doing it during toolstack
>
On Fri, Feb 21, 2020 at 07:26:49PM +, Igor Druzhinin wrote:
> On 21/02/2020 16:29, Jan Beulich wrote:
> > On 19.02.2020 18:25, Igor Druzhinin wrote:
> >> --- a/xen/arch/x86/sysctl.c
> >> +++ b/xen/arch/x86/sysctl.c
> >> @@ -78,8 +78,11 @@ static void l3_cache_get(void *arg)
> >> long cpu_up_he
On Mon, Feb 24, 2020 at 8:13 AM Roger Pau Monné wrote:
>
> On Fri, Feb 21, 2020 at 10:49:22AM -0800, Tamas K Lengyel wrote:
> > Implement hypercall that allows a fork to shed all memory that got allocated
> > for it during its execution and re-load its vCPU context from the parent VM.
> > This all
On Mon, Feb 24, 2020 at 08:35:09AM -0700, Tamas K Lengyel wrote:
> On Mon, Feb 24, 2020 at 8:13 AM Roger Pau Monné wrote:
> >
> > On Fri, Feb 21, 2020 at 10:49:22AM -0800, Tamas K Lengyel wrote:
> > > Implement hypercall that allows a fork to shed all memory that got
> > > allocated
> > > for it
On 21/02/2020 18:49, Tamas K Lengyel wrote:
> When creating a domain that will be used as a VM fork some information is
> required to set things up properly, like the max_vcpus count. Instead of the
> toolstack having to gather this information for each fork in a separate
> hypercall we can just in
On Mon, Feb 24, 2020 at 5:39 AM Roger Pau Monné wrote:
>
> On Fri, Feb 21, 2020 at 10:49:21AM -0800, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory space
> > and a
> > parent domain specified from which to populate the memory when necessary.
> > Fo
On Mon, Feb 24, 2020 at 8:42 AM Roger Pau Monné wrote:
>
> On Mon, Feb 24, 2020 at 08:35:09AM -0700, Tamas K Lengyel wrote:
> > On Mon, Feb 24, 2020 at 8:13 AM Roger Pau Monné
> > wrote:
> > >
> > > On Fri, Feb 21, 2020 at 10:49:22AM -0800, Tamas K Lengyel wrote:
> > > > Implement hypercall that
On 24/02/2020 14:43, Roger Pau Monné wrote:
> On Mon, Feb 24, 2020 at 02:22:19PM +, Andrew Cooper wrote:
>> The macros in xmalloc.h are a mix of using their type parameter directly, and
>> using typeof().
> The only ones I could spot in the neighborhood are
> xrealloc_flex_struct and xmemdup, w
Paul Durrant writes ("[PATCH v7 1/6] libxl: add infrastructure to track and
query 'recent' domids"):
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. For debugging and/or testing
> purposes the number can be set using the envir
Paul Durrant writes ("[PATCH v7 0/6] xl/libxl: domid allocation/preservation
changes"):
> Paul Durrant (6):
> libxl: add infrastructure to track and query 'recent' domids
> libxl: modify libxl__logv() to only log valid domid values
> public/xen.h: add a definition for a 'valid domid' mask
>
On Sun, Feb 23, 2020 at 11:12 PM Tomas Mozes wrote:
> As reported in
> https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00361.html
> and
> https://lists.xenproject.org/archives/html/xen-users/2020-02/msg00042.html,
> switching back to credit1 scheduler seems to make it working a
On Mon, Feb 24, 2020 at 8:45 AM Andrew Cooper wrote:
>
> On 21/02/2020 18:49, Tamas K Lengyel wrote:
> > When creating a domain that will be used as a VM fork some information is
> > required to set things up properly, like the max_vcpus count. Instead of the
> > toolstack having to gather this in
On Mon, Feb 24, 2020 at 08:45:05AM -0700, Tamas K Lengyel wrote:
> On Mon, Feb 24, 2020 at 5:39 AM Roger Pau Monné wrote:
> >
> > On Fri, Feb 21, 2020 at 10:49:21AM -0800, Tamas K Lengyel wrote:
> > > +}
> > > +
> > > +/*
> > > + * If it's a write access (ie. unsharing) or if adding a
On Mon, Feb 24, 2020 at 08:49:51AM -0700, Tamas K Lengyel wrote:
> On Mon, Feb 24, 2020 at 8:42 AM Roger Pau Monné wrote:
> >
> > On Mon, Feb 24, 2020 at 08:35:09AM -0700, Tamas K Lengyel wrote:
> > > On Mon, Feb 24, 2020 at 8:13 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Fri, Feb 21, 20
Hi Tamas,
On 21/02/2020 18:49, Tamas K Lengyel wrote:
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid)
+{
+int rc;
+struct xen_domctl_createdomain create = {0};
+create.flags |= XEN_DOMCTL_CDF_hvm;
+create.flags |= XEN_DOMCTL_CDF_hap;
+create.flags
On Mon, Feb 24, 2020 at 03:49:47PM +, Andrew Cooper wrote:
> On 24/02/2020 14:43, Roger Pau Monné wrote:
> > On Mon, Feb 24, 2020 at 02:22:19PM +, Andrew Cooper wrote:
> >> The macros in xmalloc.h are a mix of using their type parameter directly,
> >> and
> >> using typeof().
> > The only
On Mon, Feb 24, 2020 at 9:13 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 21/02/2020 18:49, Tamas K Lengyel wrote:
> > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid)
> > +{
> > +int rc;
> > +struct xen_domctl_createdomain create = {0};
> > +create.flags |= X
Hi,
On 24/02/2020 16:19, Tamas K Lengyel wrote:
On Mon, Feb 24, 2020 at 9:13 AM Julien Grall wrote:
Hi Tamas,
On 21/02/2020 18:49, Tamas K Lengyel wrote:
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid)
+{
+int rc;
+struct xen_domctl_createdomain create =
On 27/01/2020 14:34, Andrew Cooper wrote:
> These functions should never have been exposed. They don't have external
> users, and can't usefully be used for several reasons.
>
> Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
> an equivalent of the nop stubs in the API
CPUID handling needs to be earlier in construction. Move it from its current
position in libxl__build_post() to libxl__build_pre() for fresh builds, and
libxl__srm_callout_callback_static_data_done() for the migration/resume case.
Later changes will make the migration/resume case conditional on w
On Mon, Feb 24, 2020 at 9:30 AM Julien Grall wrote:
>
> Hi,
>
> On 24/02/2020 16:19, Tamas K Lengyel wrote:
> > On Mon, Feb 24, 2020 at 9:13 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 21/02/2020 18:49, Tamas K Lengyel wrote:
> >>> +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pd
> -Original Message-
> From: Ian Jackson
> Sent: 24 February 2020 15:54
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Anthony Perard ;
> George Dunlap ; Jan Beulich ;
> Jason Andryuk ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu
>
Pre Xen-4.14 streams will not contain any CPUID/MSR information. There is
nothing libxc can do about this, and will have to rely on the higher level
toolstack to provide backwards compatibility.
To facilitate this, extend the static_data_done() callback, highlighting the
missing information, and
Andrew Cooper writes ("[PATCH v2 02/17] tools/libxl: Simplify callback handling
in libxl-save-helper"):
> The {save,restore}_callback helpers can have their scope reduced vastly, and
> helper_setcallbacks_{save,restore}() doesn't need to use a ternary operator to
> write 0 (meaning NULL) into an a
Andrew Cooper writes ("[PATCH v2 03/17] tools/migration: Drop IHDR_VERSION
constant from libxc and python"):
> Migration v3 is in the process of being introduced, meaning that the code has
> to cope with both versions. Use an explicit 2 for now.
>
> For the verify-stream-v2 and convert-legacy-st
Andrew Cooper writes ("[PATCH v2 05/17] python/migration: Update validation
logic to understand a v3 stream"):
> Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
I'm not sure if I comment about manifest constants for `2' apply here.
This is a validation program, not a production tool, AIUI,
Andrew Cooper writes ("[PATCH v2 06/17] libxc/restore: Support v3 streams and
handle STATIC_DATA_END"):
> Higher level toolstacks may wish to know when the static data is complete, so
> introduce a restore_callback for the purpose.
Acked-by: Ian Jackson
_
Andrew Cooper writes ("[PATCH v2 07/17] libxc/restore: STATIC_DATA_END
inference for v2 compatibility"):
> A v3 stream can compatibly read a v2 stream by inferring the position of the
> STATIC_DATA_END record.
>
> v2 compatibility is only needed for x86. No other architectures exist yet,
> but t
On 24/02/2020 17:25, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v2 03/17] tools/migration: Drop IHDR_VERSION
> constant from libxc and python"):
>> Migration v3 is in the process of being introduced, meaning that the code has
>> to cope with both versions. Use an explicit 2 for now.
>>
>>
> -Original Message-
> From: Xen-devel On Behalf Of
> Durrant, Paul
> Sent: 24 February 2020 16:33
> To: Ian Jackson
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Jason Andryuk
> ; Andrew Cooper ; Konrad
> Rzeszutek Wilk ; George Dunlap
> ; Jan Beulich ; Anthony
> Perard ; xen-dev
Andrew Cooper writes ("[PATCH v2 10/17] tools/libxl: Plumb a restore boolean
down into libxl__build_pre()"):
> To fix CPUID handling, libxl__build_pre() is going to have to distinguish
> between a brand new VM vs one which is being migrated-in/resumed.
The distinction between libxl__build_pre and
Andrew Cooper writes ("[PATCH v2 12/17] docs/migration: Specify
X86_{CPUID,MSR}_POLICY records"):
> These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
> hypercall.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen
Durrant, Paul writes ("RE: [PATCH v7 0/6] xl/libxl: domid
allocation/preservation changes"):
> See
> https://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git;a=shortlog;h=refs/heads/domid12
Thanks. LGTM, pushed.
Ian.
___
Xen-devel mailing list
Xen-de
flight 147550 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147550/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 147487 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849
test-armhf-armhf-xl
Hi Wei,
Thank you for sending a follow-up.
On 24/02/2020 11:30, Wei Xu wrote:
Check the serial port address space before checking the address.
Could you explain in a sentence why you want to re-order?
Cheers,
Signed-off-by: Wei Xu
---
xen/drivers/char/ns16550.c | 12 ++--
1 fi
> > > +int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
> > > +{
> > > +int rc = -ENOENT;
> > > +shr_handle_t handle;
> > > +struct domain *parent;
> >
> > Can you constify parent, I assume there are no changes made to the
> > parent domain, just the forked one.
>
Hi Juergen,
On 11/02/2020 09:31, Juergen Gross wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..30c4c1830b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#inc
> > Also cd and d and not very helpful names, I would just use child and
> > parent.
>
> Sure.
Looking at this in the context of the whole pre-existing code-base,
the names cd & d are used throughout mem_sharing. So for consistency I
will keep it for now.
Tamas
__
Hi Oleksandr,
On 17/02/2020 15:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
For the IPMMU-VMSA we need to prevent the use cases where devices
which use the same micro-TLB are assigned to different Xen domains
(micro-TLB cannot be shared between multiple Xen domains, since it
poin
flight 147559 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147559/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Oleksandr-san,
> From: Oleksandr Tyshchenko, Sent: Tuesday, February 18, 2020 12:06 AM
>
> For the IPMMU-VMSA we need to prevent the use cases where devices
> which use the same micro-TLB are assigned to different Xen domains
> (micro-TLB cannot be shared between multiple Xen domains, since it
flight 147496 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
142947
test-amd64-i3
Hi Julien,
On 2020/2/25 6:03, Julien Grall wrote:
> Hi Wei,
>
> Thank you for sending a follow-up.
>
> On 24/02/2020 11:30, Wei Xu wrote:
>> Check the serial port address space before checking the address.
>
> Could you explain in a sentence why you want to re-order?
Do you think is it OK to e
flight 147500 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147500/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
139698
test-amd64-i3
On Mon, Feb 24, 2020 at 4:55 PM Glen wrote:
> On Sun, Feb 23, 2020 at 11:12 PM Tomas Mozes wrote:
> > As reported in
> https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00361.html
> and
> https://lists.xenproject.org/archives/html/xen-users/2020-02/msg00042.html,
> switching back t
flight 147520 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 147507 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
test-amd64-i3
86 matches
Mail list logo
