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
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 cases
On Fri, Sep 06, 2019 at 09:40:58AM +0200, 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.
>
>=== x86 ===
>
>* HVM guest CPU topology support (RF
flight 141226 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141226/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141033
test-armhf-armhf-libvirt-raw 13 saveresto
flight 141222 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141222/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-
flight 141218 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141218/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 141194 REGR. vs. 140844
Tests which are faili
flight 141215 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail REGR. vs. 139876
test-amd64-i386-pa
Hi George,
I made some more progress on gengotypes.py [1].
First, I implemented the KeyedUnion translation that we talked about.
You can see an example of the generated code in [2].
Second, I took a first pass at the C-to-Go type marshaling. I defined a
"marshaler" interface in [3], which allow
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 and substantially
more efficient hypercall.
Carve t
This hypercall allows the toolstack to present one combined CPUID and MSR
policy for a domain, which can be audited in one go by Xen, which is necessary
for correctness of the auditing.
Reuse the existing set_cpuid XSM access vector, as this is logically the same
operation.
As x86_cpu_policies_ar
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 policies from Xen, and mix the results as
before. Provide
This is the next part of the Xen/Toolstack CPUID/MSR work. With most of the
pieces in place, implement XEN_DOMCTL_set_cpumsr_policy to obsolete the
problematic XEN_DOMCTL_set_cpuid.
Key improvements:
1) The API supports configuring static MSR settings for the domain, a
capbility which Xen
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.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Ro
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 free()'s in the fail path.
For xc_cpuid_apply_policy(), con
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 of this logic is redundant with the policy logic in
Xe
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 various other bits of CPUID handling get cleaned up.
The domain builder no longer uses CPUID instructions for policy decisions.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/common.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/cpu/c
On Wed, 11 Sep 2019, Peng Fan wrote:
> > Subject: Re: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > + Juergen, Boris
> >
> > On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> > > Can we take a step back and figure out what we want to do here?
> > >
> > > AFAICS this function allocates
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 once. Thus, we now can check for
>> hypercall_preemp
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
>> translate_noncontig() or to limit size of one shared buffer size.
>>
>>
flight 141211 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141211/
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 did not
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 all TODOs and potential security iss
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 situation we should do two things:
>>
>> 1. Tell guest to
Andrii,
Andrii Anisov writes:
> From: Andrii Anisov
>
> 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 exec
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal
to the P2M IPA size. It is not a problem when the IOMMU can support
all values the CPU supports. In that case, the IOMMU driver woul
On Wed, 11 Sep 2019, 18:36 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
>
> So, hunting them one-by-one is the preferred w
Hi Andrii,
Andrii Anisov writes:
> From: Andrii Anisov
>
> Call time accounting hooks from appropriate transition points
> of the ARM64 code.
I'd prefer more elaborate commit message. For example - what are
appropriate transition points? I mean - how you chose ones?
> Signed-off-by: Andrii Ani
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
So, hunting them one-by-one is the preferred way? I'm asking this
because there are more of them:
% find xen/arch/arm
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 virtual address
> to be stable until unflatting the Device-Tree
On Wed, 2019-09-11 at 16:22 +0200, Juergen Gross wrote:
> On 09.09.19 15:38, Jan Beulich wrote:
> > On 09.08.2019 16:58, Juergen Gross wrote:
> > > --- a/xen/common/schedule.c
> > > +++ b/xen/common/schedule.c
> > > @@ -368,14 +368,52 @@ static struct sched_unit
> > > *sched_alloc_unit(struct vcpu
flight 141212 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141212/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7809492c10e8950a1b92581e6e87c6a4be069077
baseline version:
ovmf 000ab98574793b685e7a0
flight 141221 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141221/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141004
Tests which did
flight 141208 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 139698
test-amd64-amd64-xl-p
Hi,
On 9/11/19 5:34 PM, Oleksandr wrote:
On 10.09.19 21:55, Julien Grall wrote:
Hi,
Hi Julien
On 9/10/19 5:24 PM, Oleksandr wrote:
On 10.09.19 18:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/23/19 8:34 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
There
On 10.09.19 21:55, Julien Grall wrote:
Hi,
Hi Julien
On 9/10/19 5:24 PM, Oleksandr wrote:
On 10.09.19 18:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/23/19 8:34 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2019 15:36
> To: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony
> Perard
> Subject: [PATCH 3/3] xen: perform XenDevice clean-up in XenBus watch handler
>
> Cleaning
flight 141228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141228/
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, 2019-09-04 at 17:02 +0200, Juergen Gross wrote:
> On 04.09.19 16:54, Jan Beulich wrote:
> > On 04.09.2019 16:41, Juergen Gross wrote:
> > > On 04.09.19 16:02, Jan Beulich wrote:
> > > >
> > > > At the example of this: The more coarse granularity of the lock
> > > > means that no two vCPU-s
Steven Haigh writes ("Re: [Xen-devel] [PATCH] read grubenv and set default from
saved_entry or next_entry"):
> Just wanted to give this a quick followup... Did this end up
> progressing?
Hi. I'm a tools maintainer and probably your best bet for a review
etc of this patch. If, next time, you us
Lars Kurth writes ("[Xen-devel] [PATCH v4 3/3] Add logic to use V section entry
in THE REST for identifying xen trees"):
> Specifically:
> * Move check until after the MAINTAINERS file has been read
> * Add get_xen_maintainers_file_version() for check
> * Remove top_of_tree as not needed any more
On 11.09.19 17:06, Jan Beulich wrote:
On 11.09.2019 15:44, Juergen Gross wrote:
On 04.09.19 17:06, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -407,6 +407,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int processor
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 virtual address
to be stable until unflatting the Device-Tree.
So the relocation can safely be moved af
On 10.09.19 17:31, Julien Grall wrote:
Hi,
Hi Julien
On 9/10/19 12:04 PM, Oleksandr wrote:
On 10.09.19 00:24, Julien Grall wrote:
---help---
Enable all the required drivers for Renesas RCar3
diff --git a/xen/drivers/passthrough/Kconfig
b/xen/drivers/passthrough/Kconfig
in
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 0, which is sort of expected as no other PCID
can be activated there.
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)
#endif
+#ifndef CONFIG_PV
+# undef X86_CR4_PCIDE
+# define X86_CR4_PCIDE 0
+#e
On 11.09.19 17:20, Jan Beulich wrote:
On 11.09.2019 17:06, Juergen Gross wrote:
On 11.09.19 17:01, Jan Beulich wrote:
On 11.09.2019 15:01, Juergen Gross wrote:
And with the idea to "mount" it in the dom0 kernel's sysfs I think
xensysfs (or xenhypfs?) seems appropriate.
Well, such "mounting"
Eliminate the not really useful local variable "old". Reduce the scope
of "page". Rename the latched "current".
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2296,10 +2296,8 @@ int hvm_set_cr0(unsigned long value, boo
int hvm_set_cr3(unsigned long va
There's no need to re-obtain a page reference if only bits not affecting
the address change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2326,7 +2326,7 @@ int hvm_set_cr3(unsigned long value, boo
}
if ( hvm_paging_enabled(v) && !paging_mod
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 behavior of raising #GP(0) here is correct, but
that's not the subjec
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
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
d->arch.x87_fip_width = 4;
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2080,6 +2080,8 @@ static int hvmemul_write_cr(
HVMTRACE_LONG_2D(CR_WRITE, r
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).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/fl
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
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -103,7 +103,8 @@ static void do_tlb_flush(void)
void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
{
-
On 11.09.2019 17:06, Juergen Gross wrote:
> On 11.09.19 17:01, Jan Beulich wrote:
>> On 11.09.2019 15:01, Juergen Gross wrote:
>>> And with the idea to "mount" it in the dom0 kernel's sysfs I think
>>> xensysfs (or xenhypfs?) seems appropriate.
>>
>> Well, such "mounting" is going to be indirect, I
One line in process_multiboot_node() is using hard tab rather than soft
tab. So fix it!
Signed-off-by: Julien Grall
---
xen/arch/arm/bootfdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 258b057f00..623173bc7f 100644
-
Various CR3 and PCID related adjustments, first and foremost an
almost full re-write of switch_cr3_cr4() (in patch 2).
1: x86: adjust cr3_pcid() return type
2: x86: limit the amount of TLB flushing in switch_cr3_cr4()
3: x86/mm: honor opt_pcid also for 32-bit PV domains
4: x86/HVM: move NOFLUSH ha
On 11.09.19 17:01, Jan Beulich wrote:
On 11.09.2019 15:01, Juergen Gross wrote:
On 11.09.19 13:54, Jan Beulich wrote:
On 11.09.2019 13:29, Juergen Gross wrote:
On 11.09.19 13:17, Andrew Cooper wrote:
Second, is xenfs really the best name here? It is ambiguous with the
still-essential (even t
On 11.09.2019 15:44, Juergen Gross wrote:
> On 04.09.19 17:06, Jan Beulich wrote:
>> On 09.08.2019 16:57, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -407,6 +407,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int
>>> processor)
>>> {
>>>
On 11.09.2019 15:01, Juergen Gross wrote:
> On 11.09.19 13:54, Jan Beulich wrote:
>> On 11.09.2019 13:29, Juergen Gross wrote:
>>> On 11.09.19 13:17, Andrew Cooper wrote:
Second, is xenfs really the best name here? It is ambiguous with the
still-essential (even though it really needs to
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 watches
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 ob
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
---
Cc: Stefano Stabellini
Cc: Anth
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_...()
functions.
This patch creates a new XenWatchList data structure to allow these
in
flight 141204 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141204/
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. 140282
build-amd64-xsm
On 09.09.19 15:38, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -368,14 +368,52 @@ static struct sched_unit *sched_alloc_unit(struct vcpu *v)
return NULL;
}
-int sched_init_vcpu(struct vcpu *v, unsigned int pro
On 09.09.19 15:34, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
The credit scheduler calls vcpu_pause_nosync() and vcpu_unpause()
today. Add sched_unit_pause_nosync() and sched_unit_unpause() to
perform the same operations on scheduler units instead.
And by placing them in sche
On Fri, 2019-08-23 at 18:16 -0700, Stefano Stabellini wrote:
> On Wed, 21 Aug 2019, Dario Faggioli wrote:
> >
> > Hey, Stefano, Julien,
> >
> > Here's another patch.
> >
> > Rather than a debug patch, this is rather an actual "proposed
> > solution".
> >
> > Can you give it a go? If it works, I
On 04.09.19 17:06, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -407,6 +407,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int processor)
{
get_sched_res(v->processor)->curr = unit;
v->is_runn
On 04.09.19 16:49, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
Add the following helpers using a sched_unit as input instead of a
vcpu:
- is_idle_unit() similar to is_idle_vcpu()
- is_unit_online() similar to is_vcpu_online()
- unit_runnable() like vcpu_runnable()
Since for v
On 11.09.19 13:54, Jan Beulich wrote:
On 11.09.2019 13:29, Juergen Gross wrote:
On 11.09.19 13:17, Andrew Cooper wrote:
Second, is xenfs really the best name here? It is ambiguous with the
still-essential (even though it really needs to disappear) Linux
filesystem by the name xenfs.
Yes, I'm
On 11.09.19 13:50, Jan Beulich wrote:
On 11.09.2019 13:34, Juergen Gross wrote:
On 11.09.19 12:07, Jan Beulich wrote:
On 11.09.2019 11:57, Juergen Gross wrote:
On 11.09.19 11:30, Jan Beulich wrote:
On 11.09.2019 08:20, Juergen Gross wrote:
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
flight 141205 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 141033
Tests which did not suc
flight 141198 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 129313
test-arm64-arm64-exa
On 11.09.2019 13:29, Juergen Gross wrote:
> On 11.09.19 13:17, Andrew Cooper wrote:
>> Second, is xenfs really the best name here? It is ambiguous with the
>> still-essential (even though it really needs to disappear) Linux
>> filesystem by the name xenfs.
>
> Yes, I'm aware of that ambiguity. I'
On 11.09.2019 13:34, Juergen Gross wrote:
> On 11.09.19 12:07, Jan Beulich wrote:
>> On 11.09.2019 11:57, Juergen Gross wrote:
>>> On 11.09.19 11:30, Jan Beulich wrote:
On 11.09.2019 08:20, Juergen Gross wrote:
> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -24,6 +24,
On 9/11/19 2:41 PM, Jan Beulich wrote:
> On 11.09.2019 13:21, Razvan Cojocaru wrote:
>> On 9/11/19 1:39 PM, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 11.09.2019 12:57, Jan Beulich wrote:
On 09.09.2019 17:35, Alexandru Stefan ISAILA wrote:
> +/*
> + * Send memory access vm_events ba
On 11.09.2019 13:21, Razvan Cojocaru wrote:
> On 9/11/19 1:39 PM, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 11.09.2019 12:57, Jan Beulich wrote:
>>> On 09.09.2019 17:35, Alexandru Stefan ISAILA wrote:
+/*
+ * Send memory access vm_events based on pfec. Returns true if the event
was
On 11.09.19 12:07, Jan Beulich wrote:
On 11.09.2019 11:57, Juergen Gross wrote:
On 11.09.19 11:30, Jan Beulich wrote:
On 11.09.2019 08:20, Juergen Gross wrote:
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -24,6 +24,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
INSTALL_SBIN-$(
Hi Juergen,
On 8/9/19 3:58 PM, Juergen Gross wrote:
When scheduling an unit with multiple vcpus there is no guarantee all
vcpus are available (e.g. above maxvcpus or vcpu offline). Fall back to
idle vcpu of the current cpu in that case. This requires to store the
correct schedule_unit pointer in
On 11.09.19 13:17, Andrew Cooper wrote:
On 11/09/2019 07:19, Juergen Gross wrote:
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea
Hi Stefano,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
Add info about the SPI used for the virtual pl011.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- fix spelling
- add "multiboot,module"
- improve commit message
- improve doc
- expand the nr_spis and vpl011 sections and include
On 9/11/19 1:39 PM, Alexandru Stefan ISAILA wrote:
>
>
> On 11.09.2019 12:57, Jan Beulich wrote:
>> On 09.09.2019 17:35, Alexandru Stefan ISAILA wrote:
>>> +/*
>>> + * Send memory access vm_events based on pfec. Returns true if the event
>>> was
>>> + * sent and false for p2m_get_mem_access() er
On 11/09/2019 07:19, Juergen Gross wrote:
> On the 2019 Xen developer summit there was agreement that the Xen
> hypervisor should gain support for a hierarchical name-value store
> similar to the Linux kernel's sysfs.
>
> This is a first implementation of that idea adding the basic
> functionality
flight 141196 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141196/
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
test-amd64-i386-fre
Applied to the dma-mapping tree.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 09.08.2019 16:58, Juergen Gross wrote:
> V1:
> - add special handling for idle unit in unit_runnable() and
> unit_runnable_state()
Why was this done? Isn't vcpu_runnable() going to always return
true for idle vCPU-s?
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1255,7 +1255,
Juergen Gross writes ("[PATCH] tools: fix linking hypervisor includes to tools
include directory"):
> An incremental build of tools/include won't pickup new hypervisor
> headers in tools/include/xen. Fix that.
I personally I think trying to get this kind of thing to work properly
with recursive m
On 11.09.2019 12:57, Jan Beulich wrote:
> On 09.09.2019 17:35, Alexandru Stefan ISAILA wrote:
>> A/D bit writes (on page walks) can be considered benign by an introspection
>> agent, so receiving vm_events for them is a pessimization. We try here to
>> optimize by filtering these events out.
>> C
Hi Stefano,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
We don't have a clear way to know how many virtual SPIs we need for the
dom0-less domains. Introduce a new option under xen,domain to specify
the number of SPIs to allocate for a domain.
The property is optional. When absent, we'll use t
From: Andrii Anisov
While the Credit2 scheduler code uses guest time from the
other pcpu, we have to use locked time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig | 1 +
xen/common/sched_credit2.c | 17 +
2 files changed, 10 insertions(+), 8 deletions
From: Andrii Anisov
The locked interface to acquire guest time by scheduling code
is introduced. It can be used by schedulers what do require
guest time from a different pcpu to take scheduling decission.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig | 3 +++
xen/common/schedule.c
From: Andrii Anisov
While the RTDS scheduler code does not use guest time from the
other pcpu, we are free to go with lockless time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/sched_rt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/sched_rt.c b
From: Andrii Anisov
While the Credit scheduler code uses guest time from the
other pcpu, we have to use locked time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig| 1 +
xen/common/sched_credit.c | 12 +---
2 files changed, 6 insertions(+), 7 deletions(-)
diff
From: Andrii Anisov
The lockless interface to acquire guest time by scheduling code
is introduced. It can be used by schedulers what do not require
guest time from a different pcpu to take scheduling decission.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 10 ++
xen/inclu
From: Andrii Anisov
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 executes guests code
TACC_IDLE - the low-power st
From: Andrii Anisov
Let xentop request and show information about CPU load provided
by new time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
tools/xenstat/libxenstat/src/xenstat.c | 50 +
tools/xenstat/libxenstat/src/xenstat.h | 15 +
From: Andrii Anisov
Call time accounting hooks from appropriate transition points
of the ARM64 code.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 39 ---
xen/arch/arm/domain.c | 2 ++
2 files changed, 38 insertions(+), 3 deletions(-)
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with timing information
provided by introduced time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 33 -
xen/common/sysctl.c | 4
xen/include/publ
From: Andrii Anisov
That is the second attempt of the changes for the time accounting in XEN.
The initial topic is here [1].
In this series it is introduced a time accounting infrastructure separated
from runstates, and made an attempt to use new infra solely for taking
scheduling decissions.
T
On 09.08.2019 16:58, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -266,7 +266,7 @@ static inline void sched_unit_runstate_change(struct
> sched_unit *unit,
> struct vcpu *v = unit->vcpu_list;
>
> if ( running )
> -vcpu_runstate_change(v,
1 - 100 of 116 matches
Mail list logo
