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. 14486
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 did
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 ex
> 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 chan
> 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 lea
> 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.
>
> U
> 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
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 e24529a5c324b07dd0e55
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
test-amd64-amd
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 int
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 process_pendi
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 1
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:
> >
> > https://github.co
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
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 xmall
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 a/automation/build/suse/opensuse-tumbleweed.docke
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, that'
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, si
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 s
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ß
---
xen/common/sched/cred
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, creat
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, st
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 the
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
> func
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 un
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 @@
#defin
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 osstest
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 = pagetable_get_mfn(v->ar
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, SMP_CACHE_
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 update the exit bitmap from vmx_intr_assist into a
helper and use it in nvmx_upd
This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
The commit is wrong, as the whole point of nvmx_update_apicv is to
update the guest interrupt status field when the Ack on exit VMEXIT
control feature is enabled.
Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
---
xen/arch/x
Check whether there's a valid interrupt in VM_EXIT_INTR_INFO in order
to decide whether to update SVI in nvmx_update_apicv. If Ack on exit
is not being used VM_EXIT_INTR_INFO won't have a valid interrupt and
hence SVI shouldn't be updated to signal the interrupt is currently in
service because it w
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.
Updating RVI however is not tied to the Ack on exit feature, as it
signals the next
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 osstest with this series applied:
http://logs.test-lab.xenprojec
On 26.03.2020 16:09, Andrew Cooper wrote:
> On 26/03/2020 14:56, Jan Beulich wrote:
>> 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/mic
On 26/03/2020 14:56, Jan Beulich wrote:
> 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 mic
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), bu
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.
>
> I
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 sig
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 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, SMP_CA
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 B
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 = p2m_get_hostp2m(d
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 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 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 Micro
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 destructions
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 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 ca
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
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 1
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 CC_VERSIO
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() sh
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 s/upgr
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,
VMCB_ACCESSORS()
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 inser
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 mis
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 in
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 wou
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 a
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 requ
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 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 I'
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
> "lib
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 a
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 sp
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 b9e389d481
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(&d->page_alloc_lock);
> +domain_pause(d);
Why
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, as
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 use
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 abo
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 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 c
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 channels
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 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 pt_r
> 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 o
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 a
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 detec
> 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
> > > Ack
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 int
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 ch
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 enab
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 w
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
> > GUEST_INTR_
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
R
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 verif
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
Signed-off-by:
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 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;
> >> +struct
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 mfn
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 instanc
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
Regressions
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 in
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;
>
1 - 100 of 107 matches
Mail list logo
