On 26.03.2020 16:27, Roger Pau Monne wrote:
> Hello,
>
> osstest identified a regression caused by my earlier attempt to fix
> interrupt injection when using nested VMX. This series aims to fix the
> regression, and should unblock several osstest branches.
>
> The following report is from
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> Note that the code is now using cr3_to_mfn() to get the MFN. This is
> slightly different as the top 12-bits will now be masked.
And here I agree with the change. Hence it is even more so important
that the patch introducing
On 22.03.2020 17:14, jul...@xen.org wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -952,25 +952,27 @@ int arch_set_info_guest(
> }
> else
> {
> -unsigned long pfn = pagetable_get_pfn(v->arch.guest_table);
> +mfn_t mfn =
On 23/03/2020 08:38, Jan Beulich wrote:
> On 21.03.2020 23:19, Julien Grall wrote:
>> On Fri, 20 Mar 2020 at 21:26, Andrew Cooper
>> wrote:
>>> --- a/xen/include/xen/xmalloc.h
>>> +++ b/xen/include/xen/xmalloc.h
>>> @@ -51,6 +51,17 @@
>>> #define xmalloc_bytes(_bytes) _xmalloc(_bytes,
Code is a bit involved, and it is not easy to tell that min_rqd, inside
csched2_res_pick() is actually pointing to a runqueue, when it is
dereferenced.
Add a comment and an ASSERT() for that.
Suggested-by: Jan Beulich
Signed-off-by: Dario Faggioli
---
Cc: Jürgen Groß
---
On 26/03/2020 17:17, Dario Faggioli wrote:
> It seems that we took this code from Linux, back when the function was
> 'unsigned int' and the return value was used.
>
> But we are currently not doing anything with such value, so let's get
> rid of it and make the function void. As an anecdote,
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> We are using the 'mfn' to refer to machine frame. As this function deal
> with 'mfn', replace 'pfn' with 'mfn'.
>
> Signed-off-by: Julien Grall
>
> ---
>
> I am not entirely sure to understand the comment on top of the
>
Roger Pau Monne writes ("Re: [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by
default"):
> I would rather have it always on if possible, as gntdev or privcmd
> (when used to map foreign pages from user-space) will also require it,
> and they are not gated on XEN_BACKEND AFAICT.
Currently there
Hi Andrew,
On 26/03/2020 14:53, Andrew Cooper wrote:
On 21/03/2020 22:19, Julien Grall wrote:
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index f515ceee2a..16979a117c 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -51,6 +51,17 @@
#define
On 26.03.2020 16:38, Andrew Cooper wrote:
> On 23/03/2020 08:38, Jan Beulich wrote:
>> On 21.03.2020 23:19, Julien Grall wrote:
>>> On Fri, 20 Mar 2020 at 21:26, Andrew Cooper
>>> wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -51,6 +51,17 @@
On 3/25/20 1:11 AM, Jan Beulich wrote:
On 24.03.2020 19:39, Julien Grall wrote:
On 24/03/2020 16:13, Jan Beulich wrote:
On 24.03.2020 16:21, Hongyan Xia wrote:
From: Hongyan Xia
In contrast,
after dropping that commit, parallel domain destructions will just fail
to take the domctl lock,
On Thu, Mar 26, 2020 at 3:10 AM Roger Pau Monné wrote:
>
> On Thu, Mar 26, 2020 at 08:07:09AM +0100, Jan Beulich wrote:
> > On 25.03.2020 16:47, Roger Pau Monné wrote:
> > > On Mon, Mar 23, 2020 at 10:04:35AM -0700, Tamas K Lengyel wrote:
> > >> +static int copy_vcpu_settings(struct domain *cd,
We need python3 (and the respective -devel package), these days.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
---
.../build/suse/opensuse-tumbleweed.dockerfile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
flight 149043 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149043/
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 149063 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149063/
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 Thu, Mar 26, 2020 at 04:41:15PM +0100, Jan Beulich wrote:
> On 26.03.2020 16:27, Roger Pau Monne wrote:
> > Hello,
> >
> > osstest identified a regression caused by my earlier attempt to fix
> > interrupt injection when using nested VMX. This series aims to fix the
> > regression, and should
It seems that we took this code from Linux, back when the function was
'unsigned int' and the return value was used.
But we are currently not doing anything with such value, so let's get
rid of it and make the function void. As an anecdote, that's pretty much
the same that happened in Linux as,
On Wed, Mar 25, 2020 at 4:05 AM Roger Pau Monné wrote:
>
> Adding the PCI and IOMMU maintainers.
>
> On Mon, Mar 23, 2020 at 01:55:01PM -0700, Roman Shaposhnik wrote:
> > Hi!
> >
> > I was going through how Xen support PCIe IOMMU ACS and
> > all I could find is this:
> >
> >
> From: Roger Pau Monne
> Sent: Thursday, March 26, 2020 11:27 PM
>
> Updating SVI is required when an interrupt has been injected using the
> Ack on exit VMEXIT feature, so that the in service interrupt in the
> GUEST_INTR_STATUS matches the vector that is signaled in
> VM_EXIT_INTR_INFO.
>
>
> From: Roger Pau Monne
> Sent: Thursday, March 26, 2020 11:27 PM
>
> Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> the one performed in vmx_intr_assist might not be reached if the
> interrupt is intercepted by nvmx_intr_intercept returning true.
>
> Extract the code to
On Thu, Mar 26, 2020 at 8:53 AM Tamas K Lengyel wrote:
>
> On Thu, Mar 26, 2020 at 8:52 AM Jan Beulich wrote:
> >
> > On 26.03.2020 15:48, Tamas K Lengyel wrote:
> > > On Thu, Mar 26, 2020 at 4:17 AM Jan Beulich wrote:
> > >>
> > >> On 23.03.2020 18:04, Tamas K Lengyel wrote:
> > >>> +static
This is a simple implementation of GICD_ICACTIVER / GICD_ISACTIVER
reads. It doesn't take into account the latest state of interrupts on
other vCPUs. Only the current vCPU is up-to-date. A full solution is
not possible because it would require synchronization among all vCPUs,
which would be very
flight 149039 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
On 26/03/2020 09:19, 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().
>
> For that purpose modify
flight 149048 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149048/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f52b30e73ddee9a3a609a6e5aa87e79cf4f50879
baseline version:
ovmf
> From: Jan Beulich
> Sent: Tuesday, March 24, 2020 8:37 PM
>
> If the hardware can handle accesses, we should allow it to do so. This
> way we can expose EFRO to HVM guests, and "all" that's left for exposing
> APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
> that the
flight 149029 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs.
148873
> From: Isaila Alexandru
> Sent: Tuesday, March 24, 2020 6:46 PM
>
>
> Hi Kevin and sorry for the long reply time,
>
> On 10.03.2020 04:04, sTian, Kevin wrote:
> >> From: Alexandru Stefan ISAILA
> >> Sent: Tuesday, March 3, 2020 8:23 PM
> >>
> >> At this moment a guest can call vmfunc to
flight 149040 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149040/
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.
148666
Tests which
On 25.03.2020 17:54, Roger Pau Monné wrote:
> On Wed, Mar 25, 2020 at 04:42:07PM +, Julien Grall wrote:
>> On 25/03/2020 16:34, Tamas K Lengyel wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1270,6 +1270,9 @@ int map_vcpu_info(struct vcpu *v, unsigned long
On 26.03.20 07:58, Jan Beulich wrote:
On 25.03.2020 17:13, Julien Grall wrote:
On 25/03/2020 10:55, Juergen Gross wrote:
@@ -143,51 +143,90 @@ static int qhimark = 1;
static int qlowmark = 100;
static int rsinterval = 1000;
-struct rcu_barrier_data {
- struct rcu_head head;
-
On 26/03/2020 08:50, Jürgen Groß wrote:
On 26.03.20 09:49, Jan Beulich wrote:
On 26.03.2020 08:24, Jürgen Groß wrote:
On 26.03.20 07:58, Jan Beulich wrote:
On 25.03.2020 17:13, Julien Grall wrote:
On 25/03/2020 10:55, Juergen Gross wrote:
@@ -143,51 +143,90 @@ static int qhimark = 1;
On Tue, 2020-03-10 at 09:09 +0100, Juergen Gross wrote:
> Offlining a cpu with core scheduling active can result in a hanging
> system. Reason is the scheduling resource and unit of the to be
> removed
> cpus needs to be split in order to remove the cpu from its cpupool
> and
> move it to the idle
flight 149012 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149012/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e24529a5c324b07dd0e555206b35d1a56be834a6
baseline version:
ovmf
On 26.03.20 09:49, Jan Beulich wrote:
On 26.03.2020 08:24, Jürgen Groß wrote:
On 26.03.20 07:58, Jan Beulich wrote:
On 25.03.2020 17:13, Julien Grall wrote:
On 25/03/2020 10:55, Juergen Gross wrote:
@@ -143,51 +143,90 @@ static int qhimark = 1;
static int qlowmark = 100;
static
flight 148998 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148998/
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.
133580
> From: Roger Pau Monné
> Sent: Thursday, March 26, 2020 5:22 PM
>
> On Thu, Mar 26, 2020 at 03:17:59AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, March 25, 2020 6:19 PM
> > >
> > > Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> > > the
On 25.03.2020 16:47, Roger Pau Monné wrote:
> On Mon, Mar 23, 2020 at 10:04:35AM -0700, Tamas K Lengyel wrote:
>> +static int copy_vcpu_settings(struct domain *cd, struct domain *d)
>> +{
>> +unsigned int i;
>> +struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>> +int ret = -EINVAL;
>> +
On 26.03.2020 08:24, Jürgen Groß wrote:
> On 26.03.20 07:58, Jan Beulich wrote:
>> On 25.03.2020 17:13, Julien Grall wrote:
>>> On 25/03/2020 10:55, Juergen Gross wrote:
@@ -143,51 +143,90 @@ static int qhimark = 1;
static int qlowmark = 100;
static int rsinterval = 1000;
On Thu, Mar 26, 2020 at 08:07:09AM +0100, Jan Beulich wrote:
> On 25.03.2020 16:47, Roger Pau Monné wrote:
> > On Mon, Mar 23, 2020 at 10:04:35AM -0700, Tamas K Lengyel wrote:
> >> +static int copy_vcpu_settings(struct domain *cd, struct domain *d)
> >> +{
> >> +unsigned int i;
> >> +
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending rcu calls have finished
when returning.
As stop_machine_run() is using tasklets this requires scheduling of
idle vcpus on all cpus imposing the need to call rcu_barrier() on idle
cpus
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().
For that purpose modify process_pending_softirqs() to not allow rcu
callback processing
On Thu, Mar 26, 2020 at 03:13:56AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Wednesday, March 25, 2020 6:19 PM
> >
> > Updating SVI is required when an interrupt has been injected using the
> > Ack on exit VMEXIT feature, so that the in service interrupt in the
> >
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 dedicated percpu
counter additional to preempt_[en|dis]able() as this
Add a lock specific counter to rcu read locks in debug builds. This
allows to test for matching lock/unlock calls.
This will help to avoid cases like the one fixed by commit
98ed1f43cc2c89 where different rcu read locks were referenced in the
lock and unlock calls.
Signed-off-by: Juergen Gross
Today the RCU handling in Xen is affecting scheduling in several ways.
It is raising sched softirqs without any real need and it requires
tasklets for rcu_barrier(), which interacts badly with core scheduling.
This small series repairs those issues.
Additionally some ASSERT()s are added for
When using atomic variables for synchronization barriers are needed
to ensure proper data serialization. Introduce smp_mb__before_atomic()
and smp_mb__after_atomic() as in the Linux kernel for that purpose.
Use the same definitions as in the Linux kernel.
Suggested-by: Jan Beulich
On 26.03.2020 10:45, Juergen Gross wrote:
> Today the maximum number of event channels for a guest is defaulting
> to 1023. For large guests with lots of vcpus this is not enough, as
> e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
> guest to about 140 vcpus.
I don't think any
On 25.03.2020 17:13, Julien Grall wrote:
> On 25/03/2020 10:55, Juergen Gross wrote:
>> @@ -143,51 +143,90 @@ static int qhimark = 1;
>> static int qlowmark = 100;
>> static int rsinterval = 1000;
>> -struct rcu_barrier_data {
>> - struct rcu_head head;
>> - atomic_t *cpu_count;
>>
On Thu, Mar 26, 2020 at 08:02:22AM +0100, Jan Beulich wrote:
> On 25.03.2020 17:54, Roger Pau Monné wrote:
> > On Wed, Mar 25, 2020 at 04:42:07PM +, Julien Grall wrote:
> >> On 25/03/2020 16:34, Tamas K Lengyel wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> >
> From: Roger Pau Monné
> Sent: Thursday, March 26, 2020 5:20 PM
>
> On Thu, Mar 26, 2020 at 03:13:56AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, March 25, 2020 6:19 PM
> > >
> > > Updating SVI is required when an interrupt has been injected using the
> > >
The unwinder reports idle tasks' stack on XEN PV as unreliable which
complicates things for at least live patching. The two patches in the
series try to amend that by using similar approach as non-XEN x86 does.
v2->v3:
- change prototype of asm_cpu_bringup_and_idle()
- replace %_ASM_SP with %rsp
The unwinder reports the secondary CPU idle tasks' stack on XEN PV as
unreliable, which affects at least live patching.
cpu_initialize_context() sets up the context of the CPU through
VCPUOP_initialise hypercall. After it is woken up, the idle task starts
in cpu_bringup_and_idle() function and its
The unwinder reports the boot CPU idle task's stack on XEN PV as
unreliable, which affects at least live patching. There are two reasons
for this. First, the task does not follow the x86 convention that its
stack starts at the offset right below saved pt_regs. It allows the
unwinder to easily
Today the maximum number of event channels for a guest is defaulting
to 1023. For large guests with lots of vcpus this is not enough, as
e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
guest to about 140 vcpus.
Instead of requiring to specify the allowed number of event
On 25.03.2020 22:12, Andrew Cooper wrote:
> On 24/03/2020 12:33, Jan Beulich wrote:
>> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
>> generated header instead of (at least once per [sub]directory) into
>> CFLAGS. This results in proper rebuilds (via make dependencies) in
On 25.03.2020 19:09, Julien Grall wrote:
> Hi Jan,
>
> On 25/03/2020 15:00, Jan Beulich wrote:
>> On 22.03.2020 17:14, jul...@xen.org wrote:
>>> From: Julien Grall
>>>
>>> It is getting incredibly difficult to use typesafe GFN/MFN/PFN in the
>>> headers because of circular dependency. For
On 25.03.2020 19:21, Julien Grall wrote:
> On 25/03/2020 15:27, Jan Beulich wrote:
>> On 22.03.2020 17:14, jul...@xen.org wrote:
>>> @@ -785,21 +781,21 @@ bool is_iomem_page(mfn_t mfn)
>>> return (page_get_owner(page) == dom_io);
>>> }
>>> -static int update_xen_mappings(unsigned long
On 25.03.2020 21:58, Andrew Cooper wrote:
> On 24/03/2020 12:29, Jan Beulich wrote:
>> Note that SDM revision 070 doesn't specify exception behavior for
>> ModRM.mod == 0b11; assuming #UD here.
>
> Didn't I confirm this behaviour for you last time around?
Iirc you did, but the SDM still hasn't
On Thu, Mar 26, 2020 at 03:17:59AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Wednesday, March 25, 2020 6:19 PM
> >
> > Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> > the one performed in vmx_intr_assist might not be reached if the
> > interrupt is
On 26.03.20 10:26, Miroslav Benes wrote:
The unwinder reports the boot CPU idle task's stack on XEN PV as
unreliable, which affects at least live patching. There are two reasons
for this. First, the task does not follow the x86 convention that its
stack starts at the offset right below saved
On 26.03.20 10:26, Miroslav Benes wrote:
The unwinder reports the secondary CPU idle tasks' stack on XEN PV as
unreliable, which affects at least live patching.
cpu_initialize_context() sets up the context of the CPU through
VCPUOP_initialise hypercall. After it is woken up, the idle task starts
On 2020/3/26 0:03, Andrew Cooper wrote:
> On 25/03/2020 15:23, Pu Wen wrote:
>> On 2020/3/25 18:30, Roger Pau Monné wrote:
>>> On Tue, Mar 24, 2020 at 06:37:26PM +0800, Pu Wen wrote:
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
b/xen/include/asm-x86/hvm/svm/vmcb.h
index
On 2020/3/25 23:56, Andrew Cooper wrote:
> On 25/03/2020 15:22, Pu Wen wrote:
>> On 2020/3/24 20:28, Andrew Cooper wrote:
>>> Hmm - this field doesn't appear to be part of AVIC, which makes me
>>> wonder what we're doing without it.
>>>
>>> It appears to be a shadow copy of EFLAGS.IF which is only
On 23.03.2020 18:04, Tamas K Lengyel wrote:
> +static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
> +{
> +int rc;
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +struct page_info *page, *tmp;
> +
> +spin_lock(>page_alloc_lock);
> +domain_pause(d);
Why do
On 26.03.20 10:45, Juergen Gross wrote:
Today the maximum number of event channels for a guest is defaulting
to 1023. For large guests with lots of vcpus this is not enough, as
e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
guest to about 140 vcpus.
Instead of requiring to
flight 149005 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149005/
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
Tests which
On 24.03.2020 13:26, Jan Beulich wrote:
> Some of the later patches are still at least partly RFC, for
> varying reasons (see there). I'd appreciate though if at least
> some of the earlier ones could go in rather sooner than later.
>
> Patch 1 functionally (for the test harness) depends on
>
On 26.03.20 10:54, Jan Beulich wrote:
On 26.03.2020 10:45, Juergen Gross wrote:
Today the maximum number of event channels for a guest is defaulting
to 1023. For large guests with lots of vcpus this is not enough, as
e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
guest to
On 26.03.2020 11:00, Jürgen Groß wrote:
> On 26.03.20 10:54, Jan Beulich wrote:
>> On 26.03.2020 10:45, Juergen Gross wrote:
>>> Today the maximum number of event channels for a guest is defaulting
>>> to 1023. For large guests with lots of vcpus this is not enough, as
>>> e.g. the Linux kernel
On 26.03.20 11:05, Jan Beulich wrote:
On 26.03.2020 11:00, Jürgen Groß wrote:
On 26.03.20 10:54, Jan Beulich wrote:
On 26.03.2020 10:45, Juergen Gross wrote:
Today the maximum number of event channels for a guest is defaulting
to 1023. For large guests with lots of vcpus this is not enough,
On 25.03.2020 15:32, Andrew Cooper wrote:
> On 25/03/2020 14:16, Jan Beulich wrote:
>> On 23.03.2020 11:17, Andrew Cooper wrote:
>>> Currently, we allocate an 8 byte struct microcode_patch to point at a
>>> separately allocated struct microcode_intel. This is wasteful.
>> As indicated elsewhere
On Thu, Mar 26, 2020 at 10:50:48AM +0100, Jan Beulich wrote:
> On 25.03.2020 22:12, Andrew Cooper wrote:
> > All the requisite infrastructure looks to be already present.
>
> ... there's the one open prereq question of what happens upon
> tool chain updates. It's not clear to me if/how kconfig
The nest paging enable is actually just a single bit within the 64-bit
VMCB field, which is particularly relevant for uses like the one in
nsvm_vcpu_vmentry(). Split the field, adding definitions for a few other
bits at the same time. To be able to generate accessors for bitfields,
On 26/03/2020 13:56, Anthony PERARD wrote:
> This simple comment allows to detect when $(CC) changes version.
> Kconfig will be rerun in this case. (Rerun is forced by
> include/config.auto.cmd which detects changes of CC_VERSION_TEXT
> value).
>
> Signed-off-by: Anthony PERARD
I'd suggest
On 26.03.2020 14:56, Anthony PERARD wrote:
> This simple comment allows to detect when $(CC) changes version.
> Kconfig will be rerun in this case. (Rerun is forced by
> include/config.auto.cmd which detects changes of CC_VERSION_TEXT
> value).
>
> Signed-off-by: Anthony PERARD
Well, as said on
On 23/03/2020 12:06, Jan Beulich wrote:
> For one, subleaves within the respective union shouldn't live in
> separate sub-structures.
Oops, and of course this stays hidden right now because there is no
overlap in known bits between subleaf 0 and 1 yet.
> And then x86_cpuid_policy_fill_native()
On Thu, Mar 26, 2020 at 02:02:43PM +, Andrew Cooper wrote:
> On 26/03/2020 13:56, Anthony PERARD wrote:
> > This simple comment allows to detect when $(CC) changes version.
> > Kconfig will be rerun in this case. (Rerun is forced by
> > include/config.auto.cmd which detects changes of
flight 149054 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149054/
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 26.03.2020 14:42, Anthony PERARD wrote:
> On Thu, Mar 26, 2020 at 10:50:48AM +0100, Jan Beulich wrote:
>> On 25.03.2020 22:12, Andrew Cooper wrote:
>>> All the requisite infrastructure looks to be already present.
>>
>> ... there's the one open prereq question of what happens upon
>> tool chain
On 25/03/2020 13:51, Jan Beulich wrote:
> On 23.03.2020 11:17, Andrew Cooper wrote:
>> Implement a new get_ext_sigtable() helper to abstract the logic for
>> identifying whether an extended signature table exists. As part of this,
>> rename microcode_intel.bits to data and change its type so it
On 25/03/2020 13:41, Jan Beulich wrote:
> On 23.03.2020 11:17, Andrew Cooper wrote:
>> Every caller actually passes a struct microcode_header_intel. Implement the
>> helpers with proper types, and leave a comment explaining the Pentium Pro/II
>> behaviour with empty {data,total}size fields.
>>
>>
On Wed, 2020-03-25 at 08:11 +0100, Jan Beulich wrote:
> On 24.03.2020 19:39, Julien Grall wrote:
> > On 24/03/2020 16:13, Jan Beulich wrote:
> > > On 24.03.2020 16:21, Hongyan Xia wrote:
> > > > From: Hongyan Xia
> > > > In contrast,
> > > > after dropping that commit, parallel domain
On 25/03/2020 14:07, Jan Beulich wrote:
>> Introduce a check missing from the old code, that total_size is a multiple of
>> 1024 bytes,
> Where is this documented? The rather brief section in SDM vol 3 doesn't
> mention anything like this.
It is in the middle of the final paragraph of 9.11.1
On 26/03/2020 12:24, Jan Beulich wrote:
> On 25.03.2020 15:32, Andrew Cooper wrote:
>> On 25/03/2020 14:16, Jan Beulich wrote:
>>> On 23.03.2020 11:17, Andrew Cooper wrote:
Currently, we allocate an 8 byte struct microcode_patch to point at a
separately allocated struct microcode_intel.
On Thu, Mar 26, 2020 at 4:17 AM Jan Beulich wrote:
>
> On 23.03.2020 18:04, Tamas K Lengyel wrote:
> > +static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
> > +{
> > +int rc;
> > +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +struct page_info *page, *tmp;
> > +
On 26/03/2020 09:45, Juergen Gross wrote:
> Today the maximum number of event channels for a guest is defaulting
> to 1023. For large guests with lots of vcpus this is not enough, as
> e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
> guest to about 140 vcpus.
>
> Instead of
This simple comment allows to detect when $(CC) changes version.
Kconfig will be rerun in this case. (Rerun is forced by
include/config.auto.cmd which detects changes of CC_VERSION_TEXT
value).
Signed-off-by: Anthony PERARD
---
xen/Kconfig | 2 ++
xen/Makefile | 4
2 files changed, 6
On 26/03/2020 13:44, Pu Wen wrote:
> According to chapter "Appendix B Layout of VMCB" in the new version
> (v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
> GUEST_INTERRUPT_MASK.
>
> In current xen codes, it use whole u64 interrupt_shadow to setup
> interrupt shadow, which will
On 23.03.2020 18:04, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2202,6 +2202,17 @@ int domain_relinquish_resources(struct domain *d)
> ret = relinquish_shared_pages(d);
> if ( ret )
> return ret;
> +
> +
On 26.03.20 13:36, Andrew Cooper wrote:
On 26/03/2020 09:45, Juergen Gross wrote:
Today the maximum number of event channels for a guest is defaulting
to 1023. For large guests with lots of vcpus this is not enough, as
e.g. the Linux kernel uses 7 event channels per vcpu, limiting the
guest to
According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.
In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of
On 26.03.2020 15:48, Tamas K Lengyel wrote:
> On Thu, Mar 26, 2020 at 4:17 AM Jan Beulich wrote:
>>
>> On 23.03.2020 18:04, Tamas K Lengyel wrote:
>>> +static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
>>> +{
>>> +int rc;
>>> +struct p2m_domain *p2m =
On Thu, Mar 26, 2020 at 6:33 AM Jan Beulich wrote:
>
> On 23.03.2020 18:04, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -2202,6 +2202,17 @@ int domain_relinquish_resources(struct domain *d)
> > ret = relinquish_shared_pages(d);
> >
> On Mar 24, 2020, at 8:07 PM, Rich Persaud wrote:
>
> On Mar 24, 2020, at 14:03, George Dunlap wrote:
>>
>> I wanted to let everyone know that the XenProject is moving forward with
>> plans to hold XenSummit this year, one way or another.
>>
>> There are two basic approaches the Advisory
On 21/03/2020 22:19, Julien Grall wrote:
>> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
>> index f515ceee2a..16979a117c 100644
>> --- a/xen/include/xen/xmalloc.h
>> +++ b/xen/include/xen/xmalloc.h
>> @@ -51,6 +51,17 @@
>> #define xmalloc_bytes(_bytes) _xmalloc(_bytes,
On Thu, Mar 26, 2020 at 8:52 AM Jan Beulich wrote:
>
> On 26.03.2020 15:48, Tamas K Lengyel wrote:
> > On Thu, Mar 26, 2020 at 4:17 AM Jan Beulich wrote:
> >>
> >> On 23.03.2020 18:04, Tamas K Lengyel wrote:
> >>> +static int mem_sharing_fork_reset(struct domain *d, struct domain *pd)
> >>> +{
>
On 26.03.2020 15:35, Andrew Cooper wrote:
> On 25/03/2020 13:41, Jan Beulich wrote:
>> On 23.03.2020 11:17, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/microcode/intel.c
>>> +++ b/xen/arch/x86/cpu/microcode/intel.c
>>> @@ -46,9 +46,16 @@ struct microcode_header_intel {
>>> unsigned int
On 26.03.2020 15:41, Andrew Cooper wrote:
> On 25/03/2020 14:07, Jan Beulich wrote:
>>> Introduce a check missing from the old code, that total_size is a multiple
>>> of
>>> 1024 bytes,
>> Where is this documented? The rather brief section in SDM vol 3 doesn't
>> mention anything like this.
>
>
On 26.03.2020 15:50, Andrew Cooper wrote:
> On a perhaps tangential note, what (if anything) are you plans regarding
> backport here?
>
> These defines are ok for a transitional period across a series (and
> probably means I'll need to get the AMD side ready to be committed at
> the same time),
1 - 100 of 107 matches
Mail list logo
