At 10:34 +0200 on 05 Sep (1567679687), Jan Beulich wrote:
> This is to make the function live up to the promise its name makes. And
> it simplifies all callers.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
X
On 11.09.2019 05:52, osstest service owner wrote:
> flight 141192 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/141192/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-pvshim 16
On 11.09.2019 03:15, Igor Druzhinin wrote:
> Another thing that I implied by "not supporting" but want to explicitly
> call out is that currently Xen will refuse reserving any MCFG area
> unless it actually existed in MCFG table at boot. I don't clearly
> understand reasoning behind it but it might
On 11.09.2019 08: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
On 11.09.2019 08:19, Juergen Gross wrote:
> +# Overview
> +
> +The Hypervisor FS is a hierarchical name-value store for reporting
> +information to guests, especially dom0. It is similar to the Linux
> +kernel's sysfs, but without the functionality to directly alter
> +entries values. Entries and
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-$(CONFIG_X86) += xen-mfndump
> INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
> INSTALL_SBIN += xe
On 11.09.19 11:28, Jan Beulich wrote:
On 11.09.2019 08:19, Juergen Gross wrote:
+# Overview
+
+The Hypervisor FS is a hierarchical name-value store for reporting
+information to guests, especially dom0. It is similar to the Linux
+kernel's sysfs, but without the functionality to directly alter
Hi,
On 9/10/19 10:14 PM, Julien Grall wrote:
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
index 33f3e72b11..760434369b 100644
--- a/xen/include/asm-arm/kernel.h
+++ b/xen/include/asm-arm/kernel.h
@@ -36,6 +36,9 @@ struct kernel_info {
/* Enable pl011 emulation *
Hi Stefano,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
Read the dtb fragment corresponding to a passthrough device from memory
at the location referred to by the "multiboot,device-tree" compatible
node.
Add a new field named dtb_bootmodule to struct kernel_info to keep track
of the dtb fragm
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-$(CONFIG_X86) += xen-mfndump
INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
INST
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.
> Currently, we are fully emulating the instruction
On 11.09.19 11:24, Jan Beulich wrote:
On 11.09.2019 08: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 a
flight 141220 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141220/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4e4a850aa42f9d1573978703e69f6177190dc9f7
baseline version:
xen a342
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-$(CONFIG_X86) += xen-
Hi,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
The memory region to remap is specified by the "xen,reg" property.
The iommu is setup by passing the node of the
Hi Stefano,
On 8/21/19 4:53 AM, Stefano Stabellini wrote:
Detect "multiboot,device-tree" compatible nodes. Add them to the bootmod
array as BOOTMOD_GUEST_DTB. In kernel_probe, find the right
BOOTMOD_GUEST_DTB and store a pointer to it in dtb_bootmodule.
Signed-off-by: Stefano Stabellini
Ack
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,
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
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
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
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
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 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 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
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
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
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 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,
Applied to the dma-mapping tree.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
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
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
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 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 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 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-$(
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 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: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 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'
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
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
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
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 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 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 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 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 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
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
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
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
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
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
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.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
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
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
-
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
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)
{
-
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
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
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;
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
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
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
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"
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
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 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
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
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
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
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
> -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
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
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
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
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 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
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
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
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 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
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
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
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
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
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
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:
> 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.
>>
>>
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
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
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
1 - 100 of 116 matches
Mail list logo
