At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
On Thu, 20 Feb 2020 14:05:36 +0100
Philippe Mathieu-Daudé wrote:
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
>
> Two lines in hw/net/dp8393x.c that Coccinelle produced that
> were over 80 characters were re-wrapped by hand.
>
> Suggested-by
On Thu, 20 Feb 2020 14:05:47 +0100
Philippe Mathieu-Daudé wrote:
> Use an explicit boolean type.
>
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> scripts/coccinelle/exec_rw_const.cocci | 14 +
flight 147298 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147298/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 147140
Tests which did not succeed
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
> Hi,
>
> On 20/02/2020 17:31, 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:
Vladimir Sementsov-Ogievskiy writes:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with an errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> can't see this additional information, because
21.02.2020 10:38, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
Add functions to clean Error **errp: call corresponding Error *err
cleaning function an set pointer to NULL.
New functions:
error_free_errp
error_report_errp
warn_report_errp
Signed-off-by: Vladimir Seme
On Thu, Feb 20, 2020 at 05:01:52PM +, Durrant, Paul wrote:
> > > Hopefully what I said above illustrates why it may not be 100% common.
> >
> > Yes, that's fine. I don't expect it to be 100% common (as I guess
> > that the hooks will have different prototypes), but I expect
> > that routines c
flight 147304 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147304/
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.
142932
test-amd64-i
21.02.2020 12:19, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal and error_prepend/error_append_hint: user
can't see thi
On Fri, Feb 21, 2020 at 12:49:18AM +, Anchal Agarwal wrote:
> On Thu, Feb 20, 2020 at 10:01:52AM -0700, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Roger Pau Monné
> > > Sent: 20 February 2020 16:49
> > > To: Durrant, Paul
> > > Cc: Agarwal, Anchal ; Valentin, Eduardo
>
flight 147305 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147305/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
> -Original Message-
> From: Roger Pau Monné
> Sent: 21 February 2020 09:22
> To: Durrant, Paul
> Cc: Agarwal, Anchal ; Valentin, Eduardo
> ; len.br...@intel.com; pet...@infradead.org;
> b...@kernel.crashing.org; x...@kernel.org; linux...@kvack.org;
> pa...@ucw.cz; h...@zytor.com; t...@li
On Fri, Feb 21, 2020 at 09:56:54AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 21 February 2020 09:22
> > To: Durrant, Paul
> > Cc: Agarwal, Anchal ; Valentin, Eduardo
> > ; len.br...@intel.com; pet...@infradead.org;
> > b...@kernel.crashing.org;
On Thu, Feb 20, 2020 at 09:16:48AM +0100, Jan Beulich wrote:
> On 19.02.2020 18:03, Jan Beulich wrote:
> > On 19.02.2020 17:08, Roger Pau Monné wrote:
> >> On Wed, Feb 19, 2020 at 03:07:14PM +, Andrew Cooper wrote:
> >>> On 19/02/2020 14:57, Jan Beulich wrote:
> On 19.02.2020 15:45, Roger
On Thu, Feb 20, 2020 at 07:58:45PM +, Andrew Cooper wrote:
> A splitlock is an atomic operation which crosses a cache line boundary. It
> serialises operations in the cache coherency fabric and comes with a
> multi-thousand cycle stall.
>
> Intel Tremont CPUs introduce MSR_CORE_CAPS to enumer
Commit 2ae27137b2db89 ("x86: mm: convert dump_pagetables to use
walk_page_range") broke Xen PV guests as the hypervisor reserved hole
in the memory map was not taken into account.
Fix that by starting the kernel range only at GUARD_HOLE_END_ADDR.
Fixes: 2ae27137b2db89 ("x86: mm: convert dump_page
> -Original Message-
> From: Roger Pau Monné
> Sent: 21 February 2020 10:22
> To: Durrant, Paul
> Cc: Agarwal, Anchal ; Valentin, Eduardo
> ; len.br...@intel.com; pet...@infradead.org;
> b...@kernel.crashing.org; x...@kernel.org; linux...@kvack.org;
> pa...@ucw.cz; h...@zytor.com; t...@li
Hi Juergen,
On 21/02/2020 10:38, Juergen Gross wrote:
Commit 2ae27137b2db89 ("x86: mm: convert dump_pagetables to use
walk_page_range") broke Xen PV guests as the hypervisor reserved hole
in the memory map was not taken into account.
Fix that by starting the kernel range only at GUARD_HOLE_END_
From: Wei Liu
Since we now map and unmap Xen PTE pages, we would like to track the
lifetime of mappings so that 1) we do not dereference memory through a
variable after it is unmapped, 2) we do not unmap more than once.
Therefore, we introduce the UNMAP_DOMAIN_PAGE macro to nullify the
variable a
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
libxl: allow creation of domains with a specified or random domid
xl.conf: introduce 'domid_pol
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies libxl__domain_make() to have Xen use that value if it is valid.
If the domid value is invalid then Xen will choose the domid, as before,
unless the value is the new special RANDOM_DOMID value added to the API.
This value
This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:
"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of hav
Some code-paths use values other than INVALID_DOMID to indicate an invalid
domain id. Specifically, xl will pass a value of 0 when creating/restoring
a domain. Therefore modify libxl__logv() to use libxl_domid_valid_guest()
as a validity test.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
--
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 environment variable
LIBXL_DOMID_REUSE_TIMEOUT. If the variable does not exist then a default
value of 60s is use
A subsequent patch will modify libxl to allow selection of a random domid
value when creating domains. Valid values are limited to a width of 15 bits,
so add an appropriate mask definition to the public header.
NOTE: It is reasonable for this mask definition to be in a Xen public header
rath
This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.
NOTE: Logically it may seem as though preservation of domid should be
dealt with by libxl, but the libxl migration stream has n
On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> Rewrite the mapcache to be purely per-vCPU instead of partially per-vcpu
> and partially per-domain.
>
> The existing mapcache implementation keeps per-vcpu hash tables for
> caching, but also creates a per-domain region which is share
On Fri, Feb 21, 2020 at 10:33:42AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 21 February 2020 10:22
> > To: Durrant, Paul
> > Cc: Agarwal, Anchal ; Valentin, Eduardo
> > ; len.br...@intel.com; pet...@infradead.org;
> > b...@kernel.crashing.org;
On Sat, Feb 01, 2020 at 11:56:19AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 31 January 2020 16:08
> > To: Andrew Cooper
> > Cc: Durrant, Paul ; Ian Jackson
> > ; Anthony Perard ; xen-
> > de...@lists.xenproject.org; Wei Liu
> > Subject: Re: [Xen-deve
On Fri, Feb 21, 2020 at 11:20:45AM +, Paul Durrant wrote:
> Some code-paths use values other than INVALID_DOMID to indicate an invalid
> domain id. Specifically, xl will pass a value of 0 when creating/restoring
> a domain. Therefore modify libxl__logv() to use libxl_domid_valid_guest()
> as a
Hi Andrew,
On 19/02/2020 19:30, Andrew Cooper wrote:
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the monitor feature isn't under security support, this
doesn't need an XSA.
The CALLBACK_IRQ and {STORE,CONSOLE}_{PFN,EVTCHN} details are only
Hi,
On 21/02/2020 09:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, 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
On 21/02/2020 12:52, Xia, Hongyan wrote:
> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
>> Given that:
>>
>> 1. mapcache_domain is now a structure with only one member.
>> 2. ents is a constant throughout domain's lifecycle.
>>
>> You can replace mapcache_domain with a boolean --
>> mapcache_m
Hi Hongyan,
On 21/02/2020 10:42, Hongyan Xia wrote:
From: Wei Liu
Since we now map and unmap Xen PTE pages, we would like to track the
lifetime of mappings so that 1) we do not dereference memory through a
variable after it is unmapped, 2) we do not unmap more than once.
Therefore, we introduc
On 21.02.2020 11:23, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 09:16:48AM +0100, Jan Beulich wrote:
>> On 19.02.2020 18:03, Jan Beulich wrote:
>>> On 19.02.2020 17:08, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 03:07:14PM +, Andrew Cooper wrote:
> On 19/02/2020 14:57, Jan Be
On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> > ...
> >
> > Benchmarks
> > (baseline uses direct map instead of the mapcache in
> > map_domain_page,
> > old is the existing mapcache and new is after this patch):
> >
> > Geekbenc
On 21.02.2020 13:52, Xia, Hongyan wrote:
> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
>> On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
>>> +if ( hashmfn != mfn && !vcache->refcnt[idx] )
>>> +__clear_bit(idx, vcache->inuse);
>>
>> Also, please flush the linear addre
On 21.02.2020 10:10, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
>> Hi,
>>
>> On 20/02/2020 17:31, 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 rw
On 10/02/2020 19:21, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 3835bc928f..ccf338918d 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -36,6 +37,9 @@
> #include
> #include
> #include
> +#i
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, 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 a
On 20.02.2020 20:58, Andrew Cooper wrote:
> A splitlock is an atomic operation which crosses a cache line boundary. It
> serialises operations in the cache coherency fabric and comes with a
> multi-thousand cycle stall.
>
> Intel Tremont CPUs introduce MSR_CORE_CAPS to enumerate various core-spec
On 10/02/2020 19:21, Tamas K Lengyel wrote:
> The owner domain of shared pages is dom_cow, use that for get_page
> otherwise the function fails to return the correct page under some
> situations. The check if dom_cow should be used was only performed in
> a subset of use-cases. Fixing the error and
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, Roger Pau Monne wrote:
Allow a CPU already holding the lock in write mode to also
On 21.02.2020 03:22, Wei Xu wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1620,6 +1620,85 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
> DT_DEVICE_END
>
> #endif /* HAS_DEVICE_TREE */
> +
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM)
> +#in
On 21/02/2020 13:43, Andrew Cooper wrote:
> On 10/02/2020 19:21, Tamas K Lengyel wrote:
>> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
>> index 3835bc928f..ccf338918d 100644
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -36,6 +37,
On 23/01/2020 11:51, Jan Beulich wrote:
> The initial observation was that the mfn_valid() check comes too late:
> Neither mfn_add() nor mfn_to_page() (let alone de-referencing the
> result of the latter) are valid for MFNs failing this check. Move it up
> and - noticing that there's no caller doin
On 23/01/2020 11:51, Jan Beulich wrote:
> Throughout the function the equation
>
> pod + nonpod == (1UL << order)
>
> should hold. This has been violated by the final loop of the function:
> * changing a range from a type other than p2m_populate_on_demand to
> p2m_invalid doesn't alter the
On 06/02/2020 15:19, Jan Beulich wrote:
> PTE flags, for now at least, get stored in "unsigned int". Hence there's
> no need to widen the values to "unsigned long" before processing them.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-
On 06/02/2020 15:20, Jan Beulich wrote:
> Both callers request the host P2M's default access, which can as well be
> done inside the function. While touching this anyway, make the "gfn"
> parameter type-safe as well.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
On 21.02.2020 14:46, Jürgen Groß wrote:
> On 21.02.20 14:36, Jan Beulich wrote:
>> On 21.02.2020 10:10, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, Roger Pau Monne wrote:
> Allow a CPU already holding the lock
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, Roger Pau Monne wrote:
Allow a CPU alread
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/
On 21.02.2020 15:06, Jürgen Groß wrote:
> On 21.02.20 14:49, Julien Grall wrote:
>>
>>
>> On 21/02/2020 13:46, Jürgen Groß wrote:
>>> On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
>> Hi,
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +0
On 18/02/2020 12:21, Juergen Gross wrote:
> As rcu callbacks are processed in __do_softirq() there is no need to
> use the scheduling softirq for forcing quiescent state. Any other
> softirq would do the job and the scheduling one is the most expensive.
>
> So use the already existing rcu softirq f
On 21.02.2020 15:16, Jürgen Groß wrote:
> On 21.02.20 15:11, Julien Grall wrote:
>> Hi Juergen,
>>
>> On 21/02/2020 14:06, Jürgen Groß wrote:
>>> On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
> On 21.02.20 14:36, Jan Beulich wrote:
>> On 21.02
On 21.02.20 15:16, Jan Beulich wrote:
On 21.02.2020 15:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Gr
On Fri, Feb 21, 2020 at 6:49 AM Andrew Cooper wrote:
>
> On 10/02/2020 19:21, Tamas K Lengyel wrote:
> > The owner domain of shared pages is dom_cow, use that for get_page
> > otherwise the function fails to return the correct page under some
> > situations. The check if dom_cow should be used was
On Fri, Feb 21, 2020 at 7:02 AM Andrew Cooper wrote:
>
> On 21/02/2020 13:43, Andrew Cooper wrote:
> > On 10/02/2020 19:21, Tamas K Lengyel wrote:
> >> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> >> index 3835bc928f..ccf338918d 100644
> >> --- a/xen/arch/x86/mm/mem
On 21.02.20 15:17, Jan Beulich wrote:
On 21.02.2020 15:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On
On Fri, Feb 14, 2020 at 11:25:34PM +, Anchal Agarwal wrote:
> From: Munehisa Kamata
> Add freeze, thaw and restore callbacks for PM suspend and hibernation
> support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
> events, need to implement these xenbus_driver callbacks.
>
On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
> On 21.02.2020 10:10, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
> >> Hi,
> >>
> >> On 20/02/2020 17:31, Roger Pau Monne wrote:
> >>> Allow a CPU already holding the lock in write mode to als
On Fri, Feb 21, 2020 at 03:26:35PM +0100, Roger Pau Monné wrote:
> On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
> > On 21.02.2020 10:10, Roger Pau Monné wrote:
> > > On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
> > >> Hi,
> > >>
> > >> On 20/02/2020 17:31, Roger Pau
On 21/02/2020 14:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wr
On 21.02.20 15:32, Julien Grall wrote:
On 21/02/2020 14:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
On 21.02.20 14:36, Jan Beulich wrote:
On Fri, Feb 21, 2020 at 02:31:08PM +0100, Jan Beulich wrote:
> On 21.02.2020 13:52, Xia, Hongyan wrote:
> > On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> >> On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> >>> +if ( hashmfn != mfn && !vcache->refcnt[idx] )
> >>> +__c
On 21.02.2020 15:24, Jürgen Groß wrote:
> On 21.02.20 15:17, Jan Beulich wrote:
>> On 21.02.2020 15:16, Jürgen Groß wrote:
>>> On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
> On 21.02.20 14:49, Julien Grall wrote:
>>
>>
>>
On Fri, Feb 21, 2020 at 12:52:07PM +, Xia, Hongyan wrote:
> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> > On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> > > ...
> > >
> > > Benchmarks
> > > (baseline uses direct map instead of the mapcache in
> > > map_domain_page,
> >
On 21.02.2020 15:26, Roger Pau Monné wrote:
> On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
>> On 21.02.2020 10:10, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
Hi,
On 20/02/2020 17:31, Roger Pau Monne wrote:
> Allow a CP
On 10/02/2020 19:21, Tamas K Lengyel wrote:
> +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> +{
> +int rc = -EINVAL;
> +
> +if ( !cd->controller_pause_count )
> +return rc;
> +
> +/*
> + * We only want to get and pause the parent once, not each time this
On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
> On 21.02.2020 15:26, Roger Pau Monné wrote:
> > On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
> >> On 21.02.2020 10:10, Roger Pau Monné wrote:
> >>> On Thu, Feb 20, 2020 at 07:20:06PM +, Julien Grall wrote:
> Hi,
On 21.02.2020 15:19, Jürgen Groß wrote:
> On 21.02.20 15:16, Jan Beulich wrote:
>> On 21.02.2020 15:06, Jürgen Groß wrote:
>>> On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wrote:
> On 21.02.20 14:36, Jan Beulich wrote:
>> On 21.02.2020 10:10, Roger
On 21/02/2020 14:35, Jürgen Groß wrote:
On 21.02.20 15:32, Julien Grall wrote:
On 21/02/2020 14:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21/02/2020 13:46, Jürgen Groß wro
On 21.02.2020 15:49, Roger Pau Monné wrote:
> On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
>> On 21.02.2020 15:26, Roger Pau Monné wrote:
>>> On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
On 21.02.2020 10:10, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 0
On 21.02.2020 15:36, Wei Liu wrote:
> On Fri, Feb 21, 2020 at 02:31:08PM +0100, Jan Beulich wrote:
>> On 21.02.2020 13:52, Xia, Hongyan wrote:
>>> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> +if ( hashmfn != mfn && !v
On 21/02/2020 14:49, Roger Pau Monné wrote:
On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
Because you need to invoke smp_processor_id() to calculate the value
to use in the subtraction. I'm not meaning to say I'm entirely
opposed (seeing how much of a discussion we're having), b
On Fri, 2020-02-21 at 13:02 +, Andrew Cooper wrote:
> On 21/02/2020 12:52, Xia, Hongyan wrote:
> > On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> > > Given that:
> > >
> > > 1. mapcache_domain is now a structure with only one member.
> > > 2. ents is a constant throughout domain's lifecyc
On 21/02/2020 14:02, Jan Beulich wrote:
On 21.02.2020 03:22, Wei Xu wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1620,6 +1620,85 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
DT_DEVICE_END
#endif /* HAS_DEVICE_TREE */
+
+#if defined(CONFIG_ACPI
On Fri, Feb 21, 2020 at 03:55:28PM +0100, Jan Beulich wrote:
> On 21.02.2020 15:36, Wei Liu wrote:
> > On Fri, Feb 21, 2020 at 02:31:08PM +0100, Jan Beulich wrote:
> >> On 21.02.2020 13:52, Xia, Hongyan wrote:
> >>> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> On Thu, Feb 06, 2020 at 06
On Fri, Feb 21, 2020 at 03:52:28PM +0100, Jan Beulich wrote:
> On 21.02.2020 15:49, Roger Pau Monné wrote:
> > On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
> >> On 21.02.2020 15:26, Roger Pau Monné wrote:
> >>> On Fri, Feb 21, 2020 at 02:36:52PM +0100, Jan Beulich wrote:
> On 2
On Fri, Feb 21, 2020 at 02:56:20PM +, Julien Grall wrote:
>
>
> On 21/02/2020 14:49, Roger Pau Monné wrote:
> > On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
> > > Because you need to invoke smp_processor_id() to calculate the value
> > > to use in the subtraction. I'm not mean
On 21.02.2020 15:52, Xia, Hongyan wrote:
> On Fri, 2020-02-21 at 14:31 +0100, Jan Beulich wrote:
>> On 21.02.2020 13:52, Xia, Hongyan wrote:
>>> On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> +if ( hashmfn != mfn && !vca
On 21/02/2020 14:59, Roger Pau Monné wrote:
On Fri, Feb 21, 2020 at 02:56:20PM +, Julien Grall wrote:
On 21/02/2020 14:49, Roger Pau Monné wrote:
On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
Because you need to invoke smp_processor_id() to calculate the value
to use in
On 21.02.2020 15:57, Julien Grall wrote:
> On 21/02/2020 14:02, Jan Beulich wrote:
>> On 21.02.2020 03:22, Wei Xu wrote:
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -1620,6 +1620,85 @@ DT_DEVICE_START(ns16550, "NS16550 UART",
>>> DEVICE_SERIAL)
>>> DT_DEVICE_
On Fri, 2020-02-21 at 14:31 +0100, Jan Beulich wrote:
> On 21.02.2020 13:52, Xia, Hongyan wrote:
> > On Fri, 2020-02-21 at 11:50 +, Wei Liu wrote:
> > > On Thu, Feb 06, 2020 at 06:58:23PM +, Hongyan Xia wrote:
> > > > +if ( hashmfn != mfn && !vcache->refcnt[idx] )
> > > > +__cle
On 21.02.2020 15:58, Wei Liu wrote:
> On Fri, Feb 21, 2020 at 03:55:28PM +0100, Jan Beulich wrote:
>> On 21.02.2020 15:36, Wei Liu wrote:
>>> On Fri, Feb 21, 2020 at 02:31:08PM +0100, Jan Beulich wrote:
On 21.02.2020 13:52, Xia, Hongyan wrote:
> On Fri, 2020-02-21 at 11:50 +, Wei Liu w
On 21.02.2020 15:56, Julien Grall wrote:
> On 21/02/2020 14:49, Roger Pau Monné wrote:
>> On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
>>> Because you need to invoke smp_processor_id() to calculate the value
>>> to use in the subtraction. I'm not meaning to say I'm entirely
>>> oppo
On 21.02.20 15:51, Julien Grall wrote:
On 21/02/2020 14:35, Jürgen Groß wrote:
On 21.02.20 15:32, Julien Grall wrote:
On 21/02/2020 14:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21/02/2020 14:06, Jürgen Groß wrote:
On 21.02.20 14:49, Julien Grall wrote:
On 21.02.2020 15:58, Roger Pau Monné wrote:
> On Fri, Feb 21, 2020 at 03:52:28PM +0100, Jan Beulich wrote:
>> On 21.02.2020 15:49, Roger Pau Monné wrote:
>>> On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
On 21.02.2020 15:26, Roger Pau Monné wrote:
> On Fri, Feb 21, 2020 at 0
On 21.02.2020 16:13, Jürgen Groß wrote:
> On 21.02.20 15:51, Julien Grall wrote:
>>
>>
>> On 21/02/2020 14:35, Jürgen Groß wrote:
>>> On 21.02.20 15:32, Julien Grall wrote:
On 21/02/2020 14:16, Jürgen Groß wrote:
> On 21.02.20 15:11, Julien Grall wrote:
>> Hi Juergen,
>>
Make a start on cleaning up the constants in msr-index.h.
No functional change - only formatting changes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Pulled out of a longer series which really ought to start making some
progress.
---
xen/include/asm-x86/
On 21.02.20 16:17, Jan Beulich wrote:
On 21.02.2020 16:13, Jürgen Groß wrote:
On 21.02.20 15:51, Julien Grall wrote:
On 21/02/2020 14:35, Jürgen Groß wrote:
On 21.02.20 15:32, Julien Grall wrote:
On 21/02/2020 14:16, Jürgen Groß wrote:
On 21.02.20 15:11, Julien Grall wrote:
Hi Juergen,
On 21.02.2020 16:23, Jürgen Groß wrote:
> On 21.02.20 16:17, Jan Beulich wrote:
>> On 21.02.2020 16:13, Jürgen Groß wrote:
>>> On 21.02.20 15:51, Julien Grall wrote:
You are assuming that atomic_t will always be:
struct
{
int counter;
}
What if we decide
On 21.02.20 16:27, Jan Beulich wrote:
On 21.02.2020 16:23, Jürgen Groß wrote:
On 21.02.20 16:17, Jan Beulich wrote:
On 21.02.2020 16:13, Jürgen Groß wrote:
On 21.02.20 15:51, Julien Grall wrote:
You are assuming that atomic_t will always be:
struct
{
int counter;
}
What if we decide to
On 21.02.2020 16:19, Andrew Cooper wrote:
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -1,7 +1,74 @@
> #ifndef __ASM_MSR_INDEX_H
> #define __ASM_MSR_INDEX_H
>
> -/* CPU model specific register (MSR) numbers */
> +/*
> + * CPU model specific register (MSR)
On 19.02.20 18:25, Igor Druzhinin wrote:
During CPU down operation RCU callbacks are scheduled to finish
off some actions later as soon as CPU is fully dead (the same applies
to CPU up operation in case error path is taken). If in the same grace
period another CPU up operation is performed on the
flight 147403 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147403/
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
On 21/02/2020 15:41, Jan Beulich wrote:
> On 21.02.2020 16:19, Andrew Cooper wrote:
>> --- a/xen/include/asm-x86/msr-index.h
>> +++ b/xen/include/asm-x86/msr-index.h
>> @@ -1,7 +1,74 @@
>> #ifndef __ASM_MSR_INDEX_H
>> #define __ASM_MSR_INDEX_H
>>
>> -/* CPU model specific register (MSR) numbers
On 21.02.2020 16:59, Andrew Cooper wrote:
> On 21/02/2020 15:41, Jan Beulich wrote:
>> On 21.02.2020 16:19, Andrew Cooper wrote:
>>> --- a/xen/include/asm-x86/msr-index.h
>>> +++ b/xen/include/asm-x86/msr-index.h
>>> @@ -1,7 +1,74 @@
>>> #ifndef __ASM_MSR_INDEX_H
>>> #define __ASM_MSR_INDEX_H
>>>
1 - 100 of 148 matches
Mail list logo
