On 12.09.19 08:10, Roman Shaposhnik wrote:
Hi!
On Fri, Sep 6, 2019 at 12:41 AM Juergen Gross wrote:
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.13 so that people have an idea what is going on and
prioritise accordingly.
You're welcome
Sometimes, an ucode with a level lower than or equal to current CPU's
patch level is useful. For example, to work around a broken bios which
only loads ucode for BSP, when BSP parses an ucode blob during bootup,
it is better to save an ucode with lower or equal level for APs
No functional change
to replace the current per-cpu cache 'uci->mc'.
With the assumption that all CPUs in the system have the same signature
(family, model, stepping and 'pf'), one microcode update matches with
one cpu should match with others. Having differing microcode revisions
on cpus would cause system unstable
It ports the implementation of is_blacklisted() in linux kernel
to Xen.
Late loading may cause system hang if CPUs are affected by BDF90.
Check against BDF90 before performing a late loading.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c| 6 ++
Introduce a vendor hook, .end_update_percpu, for svm_host_osvw_init().
The hook function is called on each cpu after loading an update.
It is a preparation for spliting out apply_microcode() from
cpu_request_microcode().
Note that svm_host_osvm_init() should be called regardless of the
result of
microcode_update_lock is to prevent logic threads of a same core from
updating microcode at the same time. But due to using a global lock, it
also prevented parallel microcode updating on different cores.
Remove this lock in order to update microcode in parallel. It is safe
because we have
Major changes in version 10:
- add back the patch to call wbinvd() conditionally
- add a patch to disable late loading due to BDF90
- rendezvous CPUs in NMI handler and load ucode. But provide an option
to disable this behavior.
- avoid the call of self_nmi() on the control thread because it
apply_microcode()'s always loading the cached ucode patch forces
a patch to be stored before being loaded. Make apply_microcode()
accept a patch pointer to remove the limitation so that a patch
can be stored after a successful loading.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
During late microcode loading, apply_microcode() is invoked in
cpu_request_microcode(). To make late microcode update more reliable,
we want to put the apply_microcode() into stop_machine context. So
we split out it from cpu_request_microcode(). In general, for both
early loading on BSP and late
to a more generic function. So that it can be used alone to check
an update against the CPU signature and current update revision.
Note that enum microcode_match_result will be used in common code
(aka microcode.c), it has been placed in the common header. And
constifying the parameter of
It is needed to mitigate some issues on this specific Broadwell CPU.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index bcef668..4e5e7f9
To create a microcode patch from a vendor-specific update,
allocate_microcode_patch() copied everything from the update.
It is not efficient. Essentially, we just need to go through
ucodes in the blob, find the one with the newest revision and
install it into the microcode_patch. In the process,
During system bootup and resuming, CPUs just load the cached ucode.
So one unified function microcode_update_one() is introduced. It
takes a boolean to indicate whether ->start_update should be called.
Since early_microcode_update_cpu() is only called on BSP (APs call
the unified function),
Previously, a per-cpu ucode cache is maintained. Then each CPU had one
per-cpu update cache and there might be multiple versions of microcode.
Thus microcode_resume_cpu tried best to update microcode by loading
every update cache until a successful load.
But now the cache struct is simplified a
Remove the per-cpu cache field in struct ucode_cpu_info since it has
been replaced by a global cache. It would leads to only one field
remaining in ucode_cpu_info. Then, this struct is removed and the
remaining field (cpu signature) is stored in per-cpu area.
The cpu status notifier is also
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
Reviewed-by: Jan
When one core is loading ucode, handling NMI on sibling threads or
on other cores in the system might be problematic. By rendezvousing
all CPUs in NMI handler, it prevents NMI acceptance during ucode
loading.
Basically, some work previously done in stop_machine context is
moved to NMI handler.
On 11.09.2019 22:04, Andrew Cooper wrote:
> This helper will eventually be the core "can a guest confiured like this run
> on the CPU?" logic. For now, it is just enough of a stub to allow us to
> replace the hypercall interface while retaining the previous behaviour.
>
> It will be expanded as
flight 141229 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140282
Tests which did
Hi!
On Fri, Sep 6, 2019 at 12:41 AM Juergen Gross wrote:
>
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.13 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use
On 12.09.19 10:13, Dario Faggioli wrote:
On Fri, 2019-08-09 at 16:58 +0200, Juergen Gross wrote:
In order to prepare for multiple vcpus per schedule unit move struct
task_slice in schedule() from the local stack into struct sched_unit
of the currently running unit. To make access easier for the
On 12/09/2019 09:19, Jan Beulich wrote:
> On 11.09.2019 22:05, Andrew Cooper wrote:
>> The purpose of this change is to stop using xc_cpuid_do_domctl(), and to stop
>> basing decisions on a local CPUID instruction. This is not an appropriate
>> way
>> to construct policy information for other
On 11.09.2019 22:05, Andrew Cooper wrote:
> With the final users moved over to using XEN_DOMCTL_set_cpumsr_policy, drop
> this domctl and associated infrastructure.
>
> Rename the preexisting set_cpuid XSM vector to set_cpu_policy, now that it is
> back to having a single user.
>
>
Roger Pau Monne writes ("[PATCH] freebsd-build: fix building efifat after
r351831"):
> FreeBSD revisions after r351831 no longer automatically build an
> efifat partition image, and makefs should be used instead if such file
> is required.
>
> Do this and add logic to build the efifat partition
flight 141234 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139910
Tests which are
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set for both dom0 and any domU created by libxl if the IOMMU is
globally enabled (i.e. iommu_enabled == 1). sanitise_domain_config() is
modified
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
These are revisions of the remaining uncommitted patches from my
previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html
Paul Durrant (6):
domain: introduce XEN_DOMCTL_CDF_iommu flag
use is_iommu_enabled() where appropriate...
sysctl / libxl: report
This patch defines a new bit reported in the hw_cap field of struct
xen_sysctl_physinfo to indicate whether the platform supports sharing of
HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
whether the domain needs extra memory to store discrete IOMMU page tables
or not.
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as
On 12.09.19 12:04, Jan Beulich wrote:
On 12.09.2019 11:34, Juergen Gross wrote:
On 09.09.19 16:17, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
@@ -1825,8 +1825,9 @@ static struct task_slice
csched_schedule(
const struct scheduler *ops, s_time_t now, bool_t
On 12.09.19 13:46, Jan Beulich wrote:
On 12.09.2019 13:17, Juergen Gross wrote:
On 12.09.19 12:04, Jan Beulich wrote:
On 12.09.2019 11:34, Juergen Gross wrote:
On 09.09.19 16:17, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
@@ -1825,8 +1825,9 @@ static struct task_slice
On 11.09.2019 22:04, Andrew Cooper wrote:
> update_domain_cpuid_info() currently serves two purposes. First to merge new
> CPUID data from the toolstack, and second, to perform any necessary updating
> of derived domain/vcpu settings.
>
> The first part of this is going to be superseded by a new
On 11.09.2019 22:05, Andrew Cooper wrote:
> The purpose of this change is to stop using xc_cpuid_do_domctl(), and to stop
> basing decisions on a local CPUID instruction. This is not a correct or
> appropriate way to construct policy information for other domains.
>
> The overwhelming majority
On Wed, Sep 11, 2019 at 03:36:17PM +0100, Paul Durrant wrote:
> This patch uses the XenWatchList abstraction to add a separate watch list
> for each device. This is more scalable than walking a single notifier
> list for all watches and is also necessary to implement a bug-fix in a
> subsequent
> On 12 Sep 2019, at 12:17, Paul Durrant wrote:
>
> tools/libxl/libxl_types.idl | 1 +
> tools/ocaml/libs/xc/xenctrl.ml | 1 +
> tools/ocaml/libs/xc/xenctrl.mli | 2 +-
Acked-by: Christian Lindig
___
Xen-devel mailing list
On 11.09.2019 22:05, Andrew Cooper wrote:
> This patch is broken out just to simplify the following two.
>
> For xc_cpuid_set(), document how the 'k' works because it is quite subtle.
> Replace a memset() with weird calculation for a loop of 4 explicit NULL
> assigments. This mirrors the
On 10/09/2019 16:25, Roger Pau Monne wrote:
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 3ff67792a7..e8f5ebe929 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -401,6 +401,12 @@
> */
> #define LIBXL_HAVE_PHYSINFO_CAP_HAP 1
>
> +/*
> + *
On 12.09.2019 09:22, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -134,21 +134,11 @@ static int collect_cpu_info(unsigned int cpu_num,
> struct cpu_signature *csig)
> return 0;
> }
>
> -static inline int microcode_update_match(
> -
On Fri, 2019-08-09 at 16:58 +0200, Juergen Gross wrote:
> Today the vcpu runstate of a new scheduled vcpu is always set to
> "running" even if at that time vcpu_runnable() is already returning
> false due to a race (e.g. with pausing the vcpu).
>
> With core scheduling this can no longer work as
On Wed, 2019-09-11 at 12:30 +0200, Jan Beulich wrote:
> On 09.08.2019 16:58, Juergen Gross wrote:
> >
> > --- a/xen/include/xen/sched-if.h
> > +++ b/xen/include/xen/sched-if.h
> > @@ -75,6 +75,20 @@ static inline bool unit_runnable(const struct
> > sched_unit *unit)
> > return
On Mon, 2019-09-09 at 14:44 +0200, Juergen Gross wrote:
> ... using Dario's correct mail address
>
Thanks! :-)
> On 06.09.19 13:09, George Dunlap wrote:
> > There was a discussion on the community call about the core
> > scheduling
> > series being developed by Juergen Gross [1]. The conclusion
On Wed, Sep 11, 2019 at 05:22:51PM +0200, Jan Beulich wrote:
> I can't see any technical or performance reason why we should treat
> 32-bit PV different from 64-bit PV in this regard.
>
> Signed-off-by: Jan Beulich
The original commit mentions that PCID doesn't improve performance for
non-XPTI
Roger Pau Monne writes ("[PATCH v4 2/2] sysctl: report shadow paging
capability"):
> Report whether shadow paging is supported by the hypervisor, since it
> can be disabled at build time.
...
> NB: I'm not sure the added check in
> libxl__domain_create_info_setdefault is that useful, or if it
On 12.09.2019 12:34, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:22:51PM +0200, Jan Beulich wrote:
>> I can't see any technical or performance reason why we should treat
>> 32-bit PV different from 64-bit PV in this regard.
>>
>> Signed-off-by: Jan Beulich
>
> The original commit
On Wed, Sep 11, 2019 at 05:23:20PM +0200, Jan Beulich wrote:
> The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
> particular not when loading nested guest state.
Can't you use the current vcpu to check if the guest is in nested
mode, and avoid having to explicitly pass the
On 12/09/2019 08:52, Jan Beulich wrote:
> On 11.09.2019 22:04, Andrew Cooper wrote:
>> update_domain_cpuid_info() currently serves two purposes. First to merge new
>> CPUID data from the toolstack, and second, to perform any necessary updating
>> of derived domain/vcpu settings.
>>
>> The first
On 11.09.2019 22:05, Andrew Cooper wrote:
> @@ -935,6 +935,13 @@ int xc_cpuid_set(
> goto fail;
> }
>
> +/*
> + * Notes for following this algorithm:
> + *
> + * While it will accept any leaf data, it only makes sense to use on
> + *
On 11.09.2019 22:05, Andrew Cooper wrote:
> The purpose of this change is to stop using xc_cpuid_do_domctl(), and to stop
> basing decisions on a local CPUID instruction. This is not an appropriate way
> to construct policy information for other domains.
>
> Obtain the host and domain-max
On 11.09.2019 22:05, Andrew Cooper wrote:
> The domain builder no longer uses CPUID instructions for policy decisions.
How certain are we that there are no other components left relying
on being able to see raw CPUID output in Dom0? Sadly customers are
often doing strange things, insisting that
On Wed, Sep 11, 2019 at 03:36:16PM +0100, Paul Durrant wrote:
> Xenstore watch call-backs are already abstracted away from XenBus using
> the XenWatch data structure but the associated NotifierList manipulation
> and file handle registation is still open coded in various xen_bus_...()
On 12.09.2019 09:22, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -260,6 +260,36 @@ static enum microcode_match_result
> microcode_update_match(
> return MIS_UCODE;
> }
>
> +static bool match_cpu(const struct microcode_patch *patch)
>
On Wed, Sep 11, 2019 at 05:24:41PM +0200, Jan Beulich wrote:
> While bits 11 and below are, if not used for other purposes, reserved
> but ignored, bits beyond physical address width are supposed to raise
> exceptions (at least in the non-nested case; I'm not convinced the
> current nested SVM/VMX
On 11.09.2019 22:04, Andrew Cooper wrote:
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -229,6 +229,55 @@ int xc_get_domain_cpu_policy(xc_interface *xch, uint32_t
> domid,
> return ret;
> }
>
> +int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t domid,
>
On Wed, Sep 11, 2019 at 05:21:55PM +0200, Jan Beulich wrote:
> There's no need for it to be 64 bits wide - only the low twelve bits
> of CR3 hold the PCID.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel
On 09.09.19 16:17, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
Especially in the do_schedule() functions of the different schedulers
using smp_processor_id() for the local cpu number is correct only if
the sched_unit is a single vcpu. As soon as larger sched_units are
used most
On 12.09.2019 11:34, Juergen Gross wrote:
> On 09.09.19 16:17, Jan Beulich wrote:
>> On 09.08.2019 16:58, Juergen Gross wrote:
>>> @@ -1825,8 +1825,9 @@ static struct task_slice
>>> csched_schedule(
>>> const struct scheduler *ops, s_time_t now, bool_t
>>> tasklet_work_scheduled)
>>> {
On 12/09/2019 09:22, Jan Beulich wrote:
> On 12.09.2019 09:59, Andrew Cooper wrote:
>> On 12/09/2019 08:43, Jan Beulich wrote:
>>> On 11.09.2019 22:04, Andrew Cooper wrote:
This helper will eventually be the core "can a guest confiured like this
run
on the CPU?" logic. For now, it
On 12.09.2019 13:45, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:24:41PM +0200, Jan Beulich wrote:
>> While bits 11 and below are, if not used for other purposes, reserved
>> but ignored, bits beyond physical address width are supposed to raise
>> exceptions (at least in the non-nested
On 12.09.2019 13:53, Juergen Gross wrote:
> On 12.09.19 13:46, Jan Beulich wrote:
>> On 12.09.2019 13:17, Juergen Gross wrote:
>>> On 12.09.19 12:04, Jan Beulich wrote:
On 12.09.2019 11:34, Juergen Gross wrote:
> Okayy, I'll rename "cpu" to "my_cpu".
We've got a number of
Hello Volodymyr,
On 11.09.19 20:48, Volodymyr Babchuk wrote:
Hi Andrii,
As we agreed, I'll wipe out debugging remains as well as cleanup coding style
nits and resend the series.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
On 12/09/2019 08:43, Jan Beulich wrote:
> On 11.09.2019 22:04, Andrew Cooper wrote:
>> This helper will eventually be the core "can a guest confiured like this run
>> on the CPU?" logic. For now, it is just enough of a stub to allow us to
>> replace the hypercall interface while retaining the
flight 141224 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 129313
build-amd64-xsm
On Mon, 2019-09-09 at 11:33 +0200, Juergen Gross wrote:
> Instead of having a cpupool_dprintk() define just use debugtrace.
>
> Signed-off-by: Juergen Gross
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs,
On 12/09/2019 09:17, Jan Beulich wrote:
> On 11.09.2019 22:05, Andrew Cooper wrote:
>> @@ -935,6 +935,13 @@ int xc_cpuid_set(
>> goto fail;
>> }
>>
>> +/*
>> + * Notes for following this algorithm:
>> + *
>> + * While it will accept any leaf
On 12.09.2019 10:36, Andrew Cooper wrote:
> On 12/09/2019 09:19, Jan Beulich wrote:
>> On 11.09.2019 22:05, Andrew Cooper wrote:
>>> The purpose of this change is to stop using xc_cpuid_do_domctl(), and to
>>> stop
>>> basing decisions on a local CPUID instruction. This is not an appropriate
flight 141219 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 140999
Tests which are
On 12/09/2019 10:07, Jan Beulich wrote:
> On 11.09.2019 22:05, Andrew Cooper wrote:
>> The domain builder no longer uses CPUID instructions for policy decisions.
> How certain are we that there are no other components left relying
> on being able to see raw CPUID output in Dom0?
Cstates and Turbo
On Wed, Sep 11, 2019 at 05:22:17PM +0200, Jan Beulich wrote:
> We really need to flush the TLB just once, if we do so with or after the
> CR3 write. The only case where two flushes are unavoidable is when we
> mean to turn off CR4.PGE (perhaps just temporarily; see the code
> comment).
>
>
Hello Volodymyr,
On 11.09.19 21:01, Volodymyr Babchuk wrote:
Introduce per-pcpu time accounting what includes the following states:
TACC_HYP - the pcpu executes hypervisor code like softirq processing
(including scheduling), tasklets and context switches
TACC_GUEST - the pcpu
On Thu, Sep 12, 2019 at 12:11:55PM +0200, Jan Beulich wrote:
> On 12.09.2019 11:54, Roger Pau Monné wrote:
> > On Wed, Sep 11, 2019 at 05:22:17PM +0200, Jan Beulich wrote:
> >> We really need to flush the TLB just once, if we do so with or after the
> >> CR3 write. The only case where two flushes
> -Original Message-
> From: Anthony PERARD
> Sent: 12 September 2019 11:17
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano Stabellini
>
> Subject: Re: [PATCH 1/3] xen / notify: introduce a new XenWatchList
> abstraction
>
> On Wed, Sep 11,
On 12.09.2019 13:35, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:23:20PM +0200, Jan Beulich wrote:
>> The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
>> particular not when loading nested guest state.
>
> Can't you use the current vcpu to check if the guest is in
On Fri, 2019-08-09 at 16:58 +0200, Juergen Gross wrote:
> In order to prepare for multiple vcpus per schedule unit move struct
> task_slice in schedule() from the local stack into struct sched_unit
> of the currently running unit. To make access easier for the single
> schedulers add the pointer
On 12.09.2019 09:59, Andrew Cooper wrote:
> On 12/09/2019 08:43, Jan Beulich wrote:
>> On 11.09.2019 22:04, Andrew Cooper wrote:
>>> This helper will eventually be the core "can a guest confiured like this run
>>> on the CPU?" logic. For now, it is just enough of a stub to allow us to
>>> replace
On 12.09.2019 11:54, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:22:17PM +0200, Jan Beulich wrote:
>> We really need to flush the TLB just once, if we do so with or after the
>> CR3 write. The only case where two flushes are unavoidable is when we
>> mean to turn off CR4.PGE (perhaps just
On 12.09.19 12:04, Jan Beulich wrote:
On 12.09.2019 11:34, Juergen Gross wrote:
On 09.09.19 16:17, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
@@ -1825,8 +1825,9 @@ static struct task_slice
csched_schedule(
const struct scheduler *ops, s_time_t now, bool_t
On 12.09.2019 13:17, Juergen Gross wrote:
> On 12.09.19 12:04, Jan Beulich wrote:
>> On 12.09.2019 11:34, Juergen Gross wrote:
>>> On 09.09.19 16:17, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
> @@ -1825,8 +1825,9 @@ static struct task_slice
>csched_schedule(
On Thu, 12 Sep 2019, 13:10 Andrii Anisov, wrote:
> Hello Volodymyr,
>
> On 11.09.19 20:48, Volodymyr Babchuk wrote:
> >
> > Hi Andrii,
> >
>
> As we agreed, I'll wipe out debugging remains as well as cleanup coding
> style nits and resend the series.
This an RFC and I am sure there current
On 12.09.19 15:17, Julien Grall wrote:
This an RFC and I am sure there current state is enough to spark a discussion.
There are no need to waste time resending it and use filling up inboxes.
Please wait for more time.
Gotcha!
--
Sincerely,
Andrii Anisov.
On 12/09/2019 09:06, Jan Beulich wrote:
> On 11.09.2019 22:04, Andrew Cooper wrote:
>> --- a/tools/libxc/xc_cpuid_x86.c
>> +++ b/tools/libxc/xc_cpuid_x86.c
>> @@ -229,6 +229,55 @@ int xc_get_domain_cpu_policy(xc_interface *xch,
>> uint32_t domid,
>> return ret;
>> }
>>
>> +int
On 12/09/2019 10:11, Jan Beulich wrote:
> On 12.09.2019 10:36, Andrew Cooper wrote:
>> On 12/09/2019 09:19, Jan Beulich wrote:
>>> On 11.09.2019 22:05, Andrew Cooper wrote:
The purpose of this change is to stop using xc_cpuid_do_domctl(), and to
stop
basing decisions on a local
On 12.09.2019 15:15, Andrew Cooper wrote:
> On 12/09/2019 09:06, Jan Beulich wrote:
>> On 11.09.2019 22:04, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -294,6 +294,65 @@ static int update_domain_cpuid_info(struct domain *d,
>>> return 0;
>>> }
On 09.09.19 16:35, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -248,6 +248,20 @@ static inline void vcpu_runstate_change(
v->runstate.state = new_state;
}
+static inline void sched_unit_runstate_change(struct
> -Original Message-
> From: Jan Beulich
> Sent: 12 September 2019 14:28
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; Anthony Perard
> ; Christian Lindig ;
> George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk
>
On 12.09.19 16:05, Paul Durrant wrote:
Since commit 0629adfd80e "Actually set a HVM domain's time offset when it
sets the RTC", the comment in the public header has been misleading, since
it claims that wallclock time is only updated by control software.
Moreover, the comments stating that
flight 141238 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141238/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
baseline version:
ovmf
Xenstore watch call-backs are already abstracted away from XenBus using
the XenWatch data structure but the associated NotifierList manipulation
and file handle registration is still open coded in various xen_bus_...()
functions.
This patch creates a new XenWatchList data structure to allow these
This series fixes a potential segfault caused by NotifierList corruption
in xen-bus. The first two patches lay the groundwork and the third
actually fixes the problem.
Paul Durrant (3):
xen / notify: introduce a new XenWatchList abstraction
xen: introduce separate XenWatchList for XenDevice
On 12.09.19 16:40, Jan Beulich wrote:
On 12.09.2019 16:02, Juergen Gross wrote:
On 09.09.19 17:14, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
@@ -1002,17 +1032,17 @@ int cpu_disable_scheduler(unsigned int cpu)
* * the scheduler will always find a suitable
On 12.09.2019 16:44, Roger Pau Monné wrote:
> On a different question, AFAICT hvm_set_cr3 should never be called
> with X86_CR3_NOFLUSH set? If so, do you think it would make sense to
> add an assert to that regard?
I've been debating this with myself, and decided against for now.
We don't know
> -Original Message-
> From: Anthony PERARD
> Sent: 12 September 2019 16:04
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Stefano Stabellini
>
> Subject: Re: [PATCH v2 3/3] xen: perform XenDevice clean-up in XenBus watch
> handler
>
> On Thu, Sep 12,
On 12.09.2019 13:17, Paul Durrant wrote:
> v9:
> - Add new Kconfig option to cause 'iommu_hap_pt_share' to be defined to
>true, rather than using CONFIG_ARM, as requested by Julien
> - Assuming Jan's R-b stands since this is a mainly a cosmetic change
>directly requested by another
On 12.09.2019 15:44, Juergen Gross wrote:
> On 09.09.19 16:35, Jan Beulich wrote:
>> On 09.08.2019 16:58, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -248,6 +248,20 @@ static inline void vcpu_runstate_change(
>>> v->runstate.state = new_state;
On Thu, Sep 12, 2019 at 01:52:12PM +0200, Jan Beulich wrote:
> On 12.09.2019 13:35, Roger Pau Monné wrote:
> > On Wed, Sep 11, 2019 at 05:23:20PM +0200, Jan Beulich wrote:
> >> The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
> >> particular not when loading nested guest
On 12.09.2019 09:22, Chao Gao wrote:
> During system bootup and resuming, CPUs just load the cached ucode.
> So one unified function microcode_update_one() is introduced. It
> takes a boolean to indicate whether ->start_update should be called.
> Since early_microcode_update_cpu() is only called
This patch uses the XenWatchList abstraction to add a separate watch list
for each device. This is more scalable than walking a single notifier
list for all watches and is also necessary to implement a bug-fix in a
subsequent patch.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
1 - 100 of 170 matches
Mail list logo
