Add missing #includes.
Signed-off-by: Juergen Gross
---
xen/common/debugtrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/debugtrace.c b/xen/common/debugtrace.c
index 5d22d431ad..7313e89389 100644
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -11,7 +11,9
flight 141247 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139698
Tests which did not
flight 141256 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141240 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580
flight 141243 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 140282
flight 141244 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141244/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
build-amd64-xsm
flight 141255 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141253 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141253/
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
flight 141241 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141241/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141226
test-armhf-armhf-libvirt-raw 13
Hi,
On 9/12/19 8:45 PM, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi Volodymyr,
On 9/11/19 7:48 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
We want to limit number of calls to
Julien Grall writes:
> Hi Volodymyr,
>
> On 9/11/19 7:53 PM, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
Now we have limit for one shared buffer size, so we can be sure that
one call to
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 9/11/19 7:48 PM, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
We want to limit number of calls to lookup_and_pin_guest_ram_addr()
per one request.
Hi Volodymyr,
On 9/11/19 7:53 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
Now we have limit for one shared buffer size, so we can be sure that
one call to free_optee_shm_buf() will not free all
MAX_TOTAL_SMH_BUF_PG pages at
Hi Volodymyr,
On 9/11/19 7:48 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
We want to limit number of calls to lookup_and_pin_guest_ram_addr()
per one request. There are two ways to do this: either preempt
Hi Volodymyr,
On 9/11/19 7:41 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
On 8/23/19 8:20 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Apologies for the delay.
It is okay. I myself was busy a bit.
Julien Grall writes:
Hi,
On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
As
This results in better behaviour for the caller.
Suggested-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* New
---
tools/tests/cpu-policy/test-cpu-policy.c | 4 ++--
xen/include/xen/lib/x86/cpuid.h | 6 +++---
The domain builder no longer uses local CPUID instructions for policy
decisions. This resolves a key issue for PVH dom0's. However, as PV dom0's
have never had faulting enforced, leave a command line option to restore the
old behaviour.
In ctxt_switch_levelling(), invert the first
Hi Volodymyr,
On 9/11/19 7:32 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
There is a case possible, when OP-TEE asks guest to allocate shared
buffer, but Xen for some reason can't translate buffer's addresses. In
this
Hi Paul,
On 9/12/19 3:18 PM, Paul Durrant wrote:
My Citrix email address will expire shortly.
Good luck for the future!
Signed-off-by: Paul Durrant
Acked-by: Julien Grall
Cheers,
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad
If MCFG area is not reserved in E820, Xen by default will defer its usage
until Dom0 registers it explicitly after ACPI parser recognizes it as
a reserved resource in DSDT. Having it reserved in E820 is not
mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
and firmware is
With below testcase, guest kernel reported "No irq handler for vector":
1). Passthrough mlx ib VF to 2 pvhvm guests.
2). Start rds-stress between 2 guests.
3). Scale down 2 guests vcpu from 32 to 6 at the same time.
Repeat above test several iteration, guest kernel reported "No irq handler
Rationale: this will allow us to use get_maintainer.pl /
add_maintainers.pl scripts from xen.git
Signed-off-by: Lars Kurth
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index
flight 141237 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 140844
Tests which did not
Rationale: this will allow us to use get_maintainer.pl /
add_maintainers.pl scripts from xen.git
Signed-off-by: Lars Kurth
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index
> That looks about like we expected -- tolerable and functional, to be
> certain, but LotsOfReallyLongTypeNames.
Yeah that's definitely a down side...
> The only purpose of unions in these structures is to save space (as
> opposed to other kinds of unions are specifically designed to allow
>
On 9/10/19 9:15 PM, Igor Druzhinin wrote:
> On 10/09/2019 22:19, Boris Ostrovsky wrote:
>> On 9/10/19 4:36 PM, Igor Druzhinin wrote:
>>> On 10/09/2019 18:48, Boris Ostrovsky wrote:
On 9/10/19 5:46 AM, Igor Druzhinin wrote:
> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>> On 9/9/19
Usage of get_maintainers.pl now requires the V: entry under
THE REST to identify a MAINTAINERS file in one of the Xen
trees. See [1]
[1] lists.xenproject.org/archives/html/xen-devel/2019-09/threads.html#00263
Signed-off-by: Lars Kurth
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff
On Wed, 11 Sep 2019, Volodymyr Babchuk wrote:
>
> Julien Grall writes:
>
> > One line in process_multiboot_node() is using hard tab rather than soft
> > tab. So fix it!
> >
> > Signed-off-by: Julien Grall
> Reviewed-by: Volodymyr Babchuk
Acked-by: Stefano Stabellini
On Wed, 11 Sep 2019, Volodymyr Babchuk wrote:
> Hi Julien,
>
> Julien Grall writes:
>
> > At the moment, the Device-Tree is relocated into xenheap while setting
> > up the memory subsystem. This is actually not necessary because the
> > early mapping is still present and we don't require the
On 12/09/2019 14:15, Andrew Cooper wrote:
> 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,
flight 141236 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139876
Tests which did
flight 141250 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141250/
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
> -Original Message-
> From: Jan Beulich
> Sent: 12 September 2019 17:03
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject:
On 12.09.2019 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
On Thu, Sep 12, 2019 at 05:48:16PM +0200, Jan Beulich wrote:
> On 12.09.2019 17:31, Roger Pau Monné wrote:
> > On Wed, Sep 11, 2019 at 05:26:46PM +0200, Jan Beulich wrote:
> >> @@ -301,8 +305,12 @@ static inline void write_cr4(unsigned lo
> >> {
> >> struct cpu_info *info = get_cpu_info();
On 12.09.2019 17:42, Roger Pau Monné wrote:
> On Thu, Sep 12, 2019 at 04:47:17PM +0200, Jan Beulich wrote:
>> 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
On 12.09.2019 17:31, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:26:46PM +0200, Jan Beulich wrote:
>> @@ -301,8 +305,12 @@ static inline void write_cr4(unsigned lo
>> {
>> struct cpu_info *info = get_cpu_info();
>>
>> +#ifdef CONFIG_PV
>> /* No global pages in case of PCIDs
On 12.09.2019 17:31, Roger Pau Monné wrote:
> On Wed, Sep 11, 2019 at 05:26:46PM +0200, Jan Beulich wrote:
>> This allows in particular some streamlining of the TLB flushing code
>> paths.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@
On Thu, Sep 12, 2019 at 04:47:17PM +0200, Jan Beulich wrote:
> 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
On 12.09.2019 09:22, Chao Gao wrote:
> @@ -264,38 +336,158 @@ static int microcode_update_cpu(const struct
> microcode_patch *patch)
> return err;
> }
>
> -static long do_microcode_update(void *patch)
> +static bool wait_for_state(unsigned int state)
> +{
> +while ( loading_state !=
On Wed, Sep 11, 2019 at 05:26:46PM +0200, Jan Beulich wrote:
> This allows in particular some streamlining of the TLB flushing code
> paths.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -24,6 +24,11 @@
> #define WRAP_MASK (0x03FFU)
>
> -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 Wed, Sep 11, 2019 at 05:26:12PM +0200, Jan Beulich wrote:
> PCID validly depends on LM, as it can be enabled in Long Mode only.
> INVPCID, otoh, can be used not only without PCID enabled, but also
> outside of Long Mode altogether. In both cases its functionality is
> simply restricted to PCID
On 12.09.2019 09:22, Chao Gao wrote:
> 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
On Thu, Sep 12, 2019 at 01:16:46PM +0100, Paul Durrant wrote:
> Cleaning up offine XenDevice objects directly in
^ offline
> xen_device_backend_changed() is dangerous as xen_device_unrealize() will
> modify the watch list that is being walked. Even the QLIST_FOREACH_SAFE()
> used in
On Wed, Sep 11, 2019 at 05:25:46PM +0200, Jan Beulich wrote:
> Eliminate the not really useful local variable "old". Reduce the scope
> of "page". Rename the latched "current".
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
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
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
On Wed, Sep 11, 2019 at 05:25:18PM +0200, Jan Beulich wrote:
> There's no need to re-obtain a page reference if only bits not affecting
> the address change.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel
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
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 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 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 solution, or
>>>*
On 9/11/19 9:25 PM, Nicholas Rosbrook wrote:
> Hi George,
>
> I made some more progress on gengotypes.py [1].
[snip]
> What are your thoughts on these implementations so far?
Great! Overall it looks like it's really making progress, which is
exciting.
> First, I implemented the KeyedUnion
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 12.09.2019 15:42, Juergen Gross wrote:
> On 12.09.19 15:36, Jan Beulich wrote:
>> On 12.09.2019 15:28, Juergen Gross wrote:
>>> @@ -267,6 +288,7 @@ int _spin_trylock_recursive(spinlock_t *lock)
>>>
>>> /* Don't allow overflow of recurse_cpu field. */
>>> BUILD_BUG_ON(NR_CPUS >
My Citrix email address will expire shortly.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
MAINTAINERS | 4 ++--
1 file changed, 2
> -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
On 12.09.2019 09:22, Chao Gao wrote:
> @@ -249,49 +249,80 @@ bool microcode_update_cache(struct microcode_patch
> *patch)
> return true;
> }
>
> -static int microcode_update_cpu(const void *buf, size_t size)
> +/*
> + * Load a microcode update to current CPU.
> + *
> + * If no patch is
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 wc_sec and wc_nsec are seconds and
nanoseconds
On 09.09.19 17:14, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
@@ -504,22 +511,21 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
if ( IS_ERR(domdata) )
return PTR_ERR(domdata);
-vcpu_priv = xzalloc_array(void *, d->max_vcpus);
-if (
On 12/09/2019 10:02, 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 a correct or
>> appropriate way to construct policy information for
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
On 12.09.19 15:36, Jan Beulich wrote:
On 12.09.2019 15:28, Juergen Gross wrote:
@@ -267,6 +288,7 @@ int _spin_trylock_recursive(spinlock_t *lock)
/* Don't allow overflow of recurse_cpu field. */
BUILD_BUG_ON(NR_CPUS > SPINLOCK_NO_CPU);
+BUILD_BUG_ON(SPINLOCK_RECURSE_BITS <=
On 12.09.2019 15:28, Juergen Gross wrote:
> @@ -267,6 +288,7 @@ int _spin_trylock_recursive(spinlock_t *lock)
>
> /* Don't allow overflow of recurse_cpu field. */
> BUILD_BUG_ON(NR_CPUS > SPINLOCK_NO_CPU);
> +BUILD_BUG_ON(SPINLOCK_RECURSE_BITS <= 0);
This is too weak: While I
Print the lock profile data when the system crashes and add some more
information for each lock data (lock address, cpu holding the lock).
While at it use the PRI_stime format specifier for printing time data.
This is especially beneficial for watchdog triggered crashes in case
of deadlocks.
In
While hunting a locking problem in my core scheduling series I have
added some debugging aids to spinlock handling making it easier to
find the root cause for the problem.
Making use of the already existing lock profiling and enhancing it a
little bit produces some really valuable diagnostic data
A spinlock defined via DEFINE_SPINLOCK() as a static variable local to
a function shows up in lock profiling just with its local variable
name. This results in multiple locks just named "lock".
In order to be able to distinguish those locks in the lock profiling
output add the function name to
Add the cpu currently holding the lock to struct lock_debug. This makes
analysis of locking errors easier and it can be tested whether the
correct cpu is releasing a lock again.
Signed-off-by: Juergen Gross
---
V2:
- adjust types (Jan Beulich)
V4:
- add define for bitfield size to store cpu
Today adding locks located in a struct to lock profiling requires a
unique type index for each structure. This makes it hard to add any
new structure as the related sysctl interface needs to be changed, too.
Instead of using an index the already existing struct name specified
in
On 12.09.2019 15:18, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 12 September 2019 14:04
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
>> Andrew Cooper
>> ; Anthony Perard ;
>> Christian Lindig
>> ; George Dunlap ; Ian
>> Jackson
Instead of enabling debugging for debug builds only add a dedicated
Kconfig option for that purpose which defaults to DEBUG.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- rename to CONFIG_DEBUG_LOCKS (Jan Beulich)
---
xen/Kconfig.debug | 7 +++
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;
>>> }
> -Original Message-
> From: Jan Beulich
> Sent: 12 September 2019 14:04
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Anthony Perard ;
> Christian Lindig
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
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 13:17, Paul Durrant wrote:
> v9:
> - Added the passthrough='enabled' option to xl
> - One cosmetic change in xen
> - Assume Jan's R-b stands since non-cosmetic changes are only in the
>toolstack
Same here (I'm afraid I haven't been able to spot the cosmetic
change).
Jan
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 13:17, Paul Durrant wrote:
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -15,6 +15,9 @@
> void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> {
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
> +
> +if ( iommu_enabled &&
flight 141249 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141249/
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
On 12.09.2019 09:22, Chao Gao wrote:
> 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
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 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
Cleaning up offine XenDevice objects directly in
xen_device_backend_changed() is dangerous as xen_device_unrealize() will
modify the watch list that is being walked. Even the QLIST_FOREACH_SAFE()
used in notifier_list_notify() is insufficient as *two* notifiers (for
the frontend and backend
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
---
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 14:08, Jan Beulich wrote:
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
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 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
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.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 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 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 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 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 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
> -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 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
1 - 100 of 170 matches
Mail list logo
