Hi Jan,
On 2020/2/17 21:53, Jan Beulich wrote:
> On 03.02.2020 12:21, Wei Xu wrote:
>> Parse the ACPI SPCR table and initialize the 16550 compatible serial port
>> for ARM only. Currently we only support one UART on ARM. Some fields
>> which we do not care yet on ARM are ignored.
>>
>>
On 19.02.20 17:26, Julien Grall wrote:
On 19/02/2020 08:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned
long ulen)
+{
+ union {
+ char buf[8];
+ uint8_t u8;
+ uint16_t
On 19.02.20 16:49, Jan Beulich wrote:
On 19.02.2020 09:11, Juergen Gross wrote:
+static int hypfs_get_path_user(char *buf,
+ XEN_GUEST_HANDLE_PARAM(const_char) uaddr,
+ unsigned long ulen)
+{
+if ( ulen > XEN_HYPFS_MAX_PATHLEN )
+
On 19.02.20 19:37, Dario Faggioli wrote:
On Wed, 2020-02-19 at 17:52 +0100, Jan Beulich wrote:
On 19.02.2020 17:47, Dario Faggioli wrote:
On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -849,51 +822,71 @@ static
On 19.02.20 17:47, Dario Faggioli wrote:
On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
Currently the memory for each run-queue of the credit2 scheduler is
allocated at the scheduler's init function: for each cpu in the
system
a struct csched2_runqueue_data is being allocated, even if
On 20.02.20 07:23, Kees Cook wrote:
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get
On 19.02.20 16:57, Jan Beulich wrote:
On 19.02.2020 09:11, Juergen Gross wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_ARGO) += argo.o
obj-y += bitmap.o
obj-y += bsearch.o
+obj-y += config_data.o
In particular with embedded uses in mind, I think
flight 147265 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147265/
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 147245 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147245/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849
test-armhf-armhf-xl
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
flight 147241 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
flight 147236 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
On Wed, Feb 19, 2020 at 05:17:15PM +0100, David Hildenbrand wrote:
> Ram block notifiers are currently not aware of resizes. Especially to
> handle resizes during migration, but also to implement actually resizeable
> ram blocks (make everything between used_length and max_length
> inaccessible),
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index bbb5d47b76..fdcfb3b396 100644
--- a/tools/xenstat/xentop/xentop.c
+++
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index 13b612f26d..bbb5d47b76 100644
--- a/tools/xenstat/xentop/xentop.c
+++
Signed-off-by: Sander Eikelenboom
---
tools/xenstat/xentop/xentop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
index af11ebfbf7..13b612f26d 100644
--- a/tools/xenstat/xentop/xentop.c
+++
Fixes some fallout from: c588c002cc1 ('tools: remove tmem code and commands')
Sander Eikelenboom (3):
tools/xentop: Fix calculation of used memory.
tools/xentop: Remove dead code
tools/xentop: Cleanup some trailing whitespace
tools/xenstat/xentop/xentop.c | 16 +---
1 file
On 19/02/2020 16:44, Tamas K Lengyel wrote:
> On Mon, Feb 10, 2020 at 11:46 AM Andrew Cooper
> wrote:
>> ARM currently has no restrictions on toolstack and guest access to the entire
>> HVM_PARAM block. As the paging/monitor/sharing features aren't under
>> security
>> support, this doesn't
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the monitor feature isn't under security support, this
doesn't need an XSA.
The CALLBACK_IRQ and {STORE,CONSOLE}_{PFN,EVTCHN} details are only exposed
read-only to the guest, while MONITOR_RING_PFN
flight 147308 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147308/
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 19/02/2020 15:53, Julien Grall wrote:
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index 76b27c9168..1446d4010c 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -31,6 +31,60 @@
>> #include
>> +static int hvm_allow_set_param(const struct domain *d,
On 19/02/2020 07:48, Jan Beulich wrote:
> On 20.12.2019 22:39, Igor Druzhinin wrote:
>> @@ -38,24 +37,22 @@ void hvm_init_guest_time(struct domain *d)
>> uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_tsc)
>> {
>> struct pl_time *pl = v->domain->arch.hvm.pl_time;
>> -
On 19.02.20 18:30, Thomas Gleixner wrote:
xen_maybe_preempt_hcall() is called from the exception entry point
xen_do_hypervisor_callback with interrupts disabled.
_cond_resched() evades the might_sleep() check in cond_resched() which
would have caught that and schedule_debug() unfortunately
On Wed, 2020-02-19 at 17:52 +0100, Jan Beulich wrote:
> On 19.02.2020 17:47, Dario Faggioli wrote:
> > On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
> > > --- a/xen/common/sched/credit2.c
> > > +++ b/xen/common/sched/credit2.c
> > > @@ -849,51 +822,71 @@ static inline bool
On Tue, Feb 18, 2020 at 10:16:11AM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 11:05:53PM +, Anchal Agarwal wrote:
> > On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > > On Fri, Feb 14, 2020 at 11:25:34PM +, Anchal Agarwal wrote:
> > > > From: Munehisa
On Wed, Feb 19, 2020 at 11:44:11AM +, Wei Liu wrote:
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> *
Adapt the hypervisor ops framework so it can be used with the
alternative calls framework. So far no hooks are modified to make use
of the alternatives patching, as they are not in any hot path.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
Reviewed-by:
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Hello,
The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.
Only the HAP guest TLB flush is improved, the shadow paging TLB flush is
left as-is, and can be improved later if there's interest.
For a reference
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32
xen_maybe_preempt_hcall() is called from the exception entry point
xen_do_hypervisor_callback with interrupts disabled.
_cond_resched() evades the might_sleep() check in cond_resched() which
would have caught that and schedule_debug() unfortunately lacks a check
for irqs_disabled().
Enable
During CPU down operation RCU callbacks are scheduled to finish
off some actions later as soon as CPU is fully dead (the same applies
to CPU up operation in case error path is taken). If in the same grace
period another CPU up operation is performed on the same CPU, RCU callback
will be called
Hello Oleksandr,
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> For the IPMMU-VMSA we need to prevent the use cases where devices
> which use the same micro-TLB are assigned to different Xen domains
> (micro-TLB cannot be shared between multiple Xen domains, since it
> points to
On 19.02.2020 17:26, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 05:06:20PM +0100, Jan Beulich wrote:
>> On 19.02.2020 16:07, Andrew Cooper wrote:
>>> On 19/02/2020 14:57, Jan Beulich wrote:
On 19.02.2020 15:45, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan
On 19.02.2020 17:08, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 03:07:14PM +, Andrew Cooper wrote:
>> On 19/02/2020 14:57, Jan Beulich wrote:
>>> On 19.02.2020 15:45, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger
On 19.02.2020 10:18, Alexandru Stefan ISAILA wrote:
> @@ -4835,6 +4836,23 @@ static int do_altp2m_op(
> break;
> }
>
> +case HVMOP_altp2m_set_visibility:
> +{
> +uint16_t altp2m_idx = a.u.set_visibility.altp2m_idx;
> +
> +if ( a.u.set_visibility.pad )
> +
On 19/02/2020 16:06, Jan Beulich wrote:
> On 19.02.2020 16:07, Andrew Cooper wrote:
>> On 19/02/2020 14:57, Jan Beulich wrote:
>>> On 19.02.2020 15:45, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
>>
On 19.02.2020 17:47, Dario Faggioli wrote:
> On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
>> --- a/xen/common/sched/credit2.c
>> +++ b/xen/common/sched/credit2.c
>> @@ -849,51 +822,71 @@ static inline bool same_core(unsigned int cpua,
>> unsigned int cpub)
>>
On 18/02/2020 13:15, Igor Druzhinin wrote:
> On 18/02/2020 12:21, Juergen Gross wrote:
>> 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
On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
> Currently the memory for each run-queue of the credit2 scheduler is
> allocated at the scheduler's init function: for each cpu in the
> system
> a struct csched2_runqueue_data is being allocated, even if the
> current scheduler only handles
On 19/02/2020 16:26, Julien Grall wrote:
On 19/02/2020 08:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned
long ulen)
+{
+ union {
+ char buf[8];
+ uint8_t u8;
+
On 19.02.2020 09:11, Juergen Gross wrote:
> --- a/docs/misc/hypfs-paths.pandoc
> +++ b/docs/misc/hypfs-paths.pandoc
> @@ -152,3 +152,12 @@ The major version of Xen.
> /buildinfo/version/minor = INTEGER
>
> The minor version of Xen.
> +
> + /params/
> +
> +A directory of runtime
On Mon, Feb 10, 2020 at 11:46 AM Andrew Cooper
wrote:
>
> ARM currently has no restrictions on toolstack and guest access to the entire
> HVM_PARAM block. As the paging/monitor/sharing features aren't under security
> support, this doesn't need an XSA.
There is no paging or sharing
On 19/02/2020 08:12, Jan Beulich wrote:
> This is controlling Xen behavior alone, after all.
>
> Reported-by: Jin Nan Wang
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Wed, Feb 19, 2020 at 2:19 AM Alexandru Stefan ISAILA
wrote:
>
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
>
On Wed, Feb 19, 2020 at 05:06:20PM +0100, Jan Beulich wrote:
> On 19.02.2020 16:07, Andrew Cooper wrote:
> > On 19/02/2020 14:57, Jan Beulich wrote:
> >> On 19.02.2020 15:45, Roger Pau Monné wrote:
> >>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger
On 19/02/2020 08:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+union {
+char buf[8];
+uint8_t u8;
+uint16_t u16;
+uint32_t u32;
+
If we skip the bootloader, the TTY path will be set for xenconsoled.
However, there is no guarantee that this will happen by the time we
want to call the console_available callback, so we have to wait.
Signed-off-by: Paweł Marczewski
---
tools/libxl/libxl_create.c | 33
Hi,
On 19/02/2020 15:49, Jan Beulich wrote:
On 19.02.2020 09:11, Juergen Gross wrote:
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+union {
+char buf[8];
+uint8_t u8;
+uint16_t
Ram block notifiers are currently not aware of resizes. Especially to
handle resizes during migration, but also to implement actually resizeable
ram blocks (make everything between used_length and max_length
inaccessible), we want to teach ram block notifiers about resizeable
ram.
Introduce the
On Wed, Feb 19, 2020 at 03:07:14PM +, Andrew Cooper wrote:
> On 19/02/2020 14:57, Jan Beulich wrote:
> > On 19.02.2020 15:45, Roger Pau Monné wrote:
> >> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> >>> On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020
On 19.02.2020 16:07, Andrew Cooper wrote:
> On 19/02/2020 14:57, Jan Beulich wrote:
>> On 19.02.2020 15:45, Roger Pau Monné wrote:
>>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan
On Wed, 2020-02-19 at 16:33 +0100, Juergen Gross wrote:
> Having interrupts disabled all the time when running dump_runq() is
> not necessary. All the called functions are doing proper locking
> and disable interrupts if needed.
>
> Signed-off-by: Juergen Gross
>
As said, I'm fine with this
On 19.02.2020 09:11, Juergen Gross wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ARGO) += argo.o
> obj-y += bitmap.o
> obj-y += bsearch.o
> +obj-y += config_data.o
In particular with embedded uses in mind, I think this wants to
have a Kconfig
Hi Andrew,
Thank you for stepping up and trying to make HVM_PARAM better :).
On 10/02/2020 18:45, Andrew Cooper wrote:
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the paging/monitor/sharing features aren't under security
support, this
On 19.02.2020 09:11, Juergen Gross wrote:
> +static int hypfs_get_path_user(char *buf,
> + XEN_GUEST_HANDLE_PARAM(const_char) uaddr,
> + unsigned long ulen)
> +{
> +if ( ulen > XEN_HYPFS_MAX_PATHLEN )
> +return -EINVAL;
> +
>
On Wed, 2020-02-19 at 16:02 +0100, Jürgen Groß wrote:
> On 19.02.20 15:27, Jan Beulich wrote:
> > On 13.02.2020 13:54, Juergen Gross wrote:
> > > All dumping functions invoked by the "runq" keyhandler are called
> > > with
> > > disabled interrupts,
> >
> > Is this actually needed for anything?
On 19/02/2020 13:37, Jan Beulich wrote:
> Quite possibly they had been in use when some of the PCI interfacing was
> done in an ad hoc way rather than using the PCI functions we have. Right
> now these have no users (left).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Having interrupts disabled all the time when running dump_runq() is
not necessary. All the called functions are doing proper locking
and disable interrupts if needed.
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
flight 147229 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
flight 147297 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147297/
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 Wed, Feb 19, 2020 at 01:48:39PM +, Ian Jackson wrote:
> Hi. This message is being sent once to each mailing list hosted by
> the Xen Project.
>
> Increasingly, mail systems on the public internet are demanding
> restrictive SPF configurations [1] and DKIM signatures [2].
>
> Currently the
On 19.02.20 15:31, Dario Faggioli wrote:
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
Instead of using the normal locks use the keyhandler provided
trylocks
with timeouts. This requires a special primitive for the scheduler
lock.
So, FWIW, I tend to agree with Andrew on the general
On 19/02/2020 14:57, Jan Beulich wrote:
> On 19.02.2020 15:45, Roger Pau Monné wrote:
>> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
>>> On 19.02.2020 14:22, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger
flight 147222 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147222/
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.
142932
On 19.02.20 15:27, Jan Beulich wrote:
On 13.02.2020 13:54, Juergen Gross wrote:
All dumping functions invoked by the "runq" keyhandler are called with
disabled interrupts,
Is this actually needed for anything? It means not servicing
interrupts for perhaps an extended period of time. Debug
On 19/02/2020 13:44, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
>> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
>>> On 13.02.2020 12:32, Roger Pau Monne wrote:
Don't allow cpu_hotplug_begin to fail by converting the trylock into a
blocking lock
On 19.02.2020 15:45, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
>> On 19.02.2020 14:22, Roger Pau Monné wrote:
>>> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
On 13.02.2020 12:32, Roger Pau Monne wrote:
> Don't allow
Jürgen Groß writes:
> On 19.02.20 12:01, Thomas Gleixner wrote:
>> xen_maybe_preempt_hcall() is called from the exception entry point
>> xen_do_hypervisor_callback with interrupts disabled.
>>
>> _cond_resched() evades the might_sleep() check in cond_resched() which
>> would have caught that
On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
> > On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> >> On 13.02.2020 12:32, Roger Pau Monne wrote:
> >>> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that
On Wed, Feb 19, 2020 at 02:42:58PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:19, Roger Pau Monné wrote:
> > On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
> >> On 13.02.2020 12:32, Roger Pau Monne wrote:
> >>> void __init register_cpu_notifier(struct notifier_block *nb)
> >>> {
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
> Instead of using the normal locks use the keyhandler provided
> trylocks
> with timeouts. This requires a special primitive for the scheduler
> lock.
>
So, FWIW, I tend to agree with Andrew on the general aspects of this.
I.e., I
On 13.02.2020 13:54, Juergen Gross wrote:
> All dumping functions invoked by the "runq" keyhandler are called with
> disabled interrupts,
Is this actually needed for anything? It means not servicing
interrupts for perhaps an extended period of time. Debug keys
aren't promised to be non-intrusive,
Hi. This message is being sent once to each mailing list hosted by
the Xen Project.
Increasingly, mail systems on the public internet are demanding
restrictive SPF configurations [1] and DKIM signatures [2].
Currently the Xen Project systems have liberal configurations.
Unfortunately this means
On 19.02.2020 14:22, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
>> On 13.02.2020 12:32, Roger Pau Monne wrote:
>>> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
>>> blocking lock acquisition. Write users of the cpu_add_remove_lock
On 19.02.2020 14:19, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
>> On 13.02.2020 12:32, Roger Pau Monne wrote:
>>> void __init register_cpu_notifier(struct notifier_block *nb)
>>> {
>>> -if ( !spin_trylock(_add_remove_lock) )
>>> +if (
Hi Daniel,
Thank you for the patch.
On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
I'd split this patch in two then, with the Xen first coming
Quite possibly they had been in use when some of the PCI interfacing was
done in an ad hoc way rather than using the PCI functions we have. Right
now these have no users (left).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu-defs.h
+++
On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger Pau Monne wrote:
> > Don't allow cpu_hotplug_begin to fail by converting the trylock into a
> > blocking lock acquisition. Write users of the cpu_add_remove_lock are
> > limited to CPU plug/unplug operations,
On Wed, Feb 19, 2020 at 01:56:02PM +0100, Jan Beulich wrote:
> On 13.02.2020 12:32, Roger Pau Monne wrote:
> > void __init register_cpu_notifier(struct notifier_block *nb)
> > {
> > -if ( !spin_trylock(_add_remove_lock) )
> > +if ( !write_trylock(_add_remove_lock) )
> > BUG();
On 19/02/2020 12:49, Jan Beulich wrote:
Julien,
On 18.02.2020 17:53, Andrew Cooper wrote:
On 18/02/2020 16:52, Jan Beulich wrote:
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range, to avoid returning
the less applicable -ENOMEM in such cases
On 13.02.2020 12:32, Roger Pau Monne wrote:
> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
> blocking lock acquisition. Write users of the cpu_add_remove_lock are
> limited to CPU plug/unplug operations, and cannot deadlock between
> themselves or other users taking the
On 13.02.2020 12:32, Roger Pau Monne wrote:
> void __init register_cpu_notifier(struct notifier_block *nb)
> {
> -if ( !spin_trylock(_add_remove_lock) )
> +if ( !write_trylock(_add_remove_lock) )
> BUG(); /* Should never fail as we are called only during boot. */
>
Julien,
On 18.02.2020 17:53, Andrew Cooper wrote:
> On 18/02/2020 16:52, Jan Beulich wrote:
>> This is more robust than the raw xmalloc_bytes().
>>
>> Also add a sanity check on the input page range, to avoid returning
>> the less applicable -ENOMEM in such cases (and trying the allocation in
>>
On 19.02.2020 12:32, Roger Pau Monné wrote:
> On Wed, Feb 19, 2020 at 11:23:40AM +, Andrew Cooper wrote:
>> On 19/02/2020 11:19, Roger Pau Monne wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>>> @@ -338,6 +338,7 @@ static int
On Thu, 2020-02-13 at 13:54 +0100, Juergen Gross wrote:
> All dumping functions invoked by the "runq" keyhandler are called
> with
> disabled interrupts, so there is no need to use the irqsave variants
> of any locks in those functions.
>
>
To me, this patch looks pretty independent from the
On Thu, 2020-02-13 at 15:35 +0100, Juergen Gross wrote:
> get_cpu_idle_time() is calling vcpu_runstate_get() for an idle vcpu.
> With core scheduling active this is fragile, as idle vcpus are
> assigned
> to other scheduling units temporarily, and that assignment is changed
> in some cases without
On 13/02/2020 11:32, Roger Pau Monne wrote:
> Hello,
>
> The main aim of this series is to reduce the pressure around
> cpu_add_remove_lock by converting it into a rw lock. Most users of the
> lock want to take it in read mode, as they only care about the maps not
> changing.
>
> Patch #2 makes
On 2/19/20 12:20 PM, Daniel Vetter wrote:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_dev_alloc(). We need to remove the kfree from
>
Hi Jan,
On 14/02/2020 09:37, Jan Beulich wrote:
On 13.02.2020 19:38, Andrew Cooper wrote:
On 13/02/2020 12:54, Juergen Gross wrote:
Keyhandlers dumping hypervisor information to the console often need
to take locks while accessing data. In order to not block in case of
system inconsistencies
flight 147221 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147221/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 147140
Hi Roger,
On 13/02/2020 11:32, Roger Pau Monne wrote:
Most users of the cpu maps just care about the maps not changing while
the lock is being held, but don't actually modify the maps.
Convert the lock into a rw lock, and take the lock in read mode in
get_cpu_maps and in write mode in
On Wed, Feb 19, 2020 at 09:11:19AM +0100, Juergen Gross wrote:
> Add a new script xen/tools/binfile for including a binary file at build
> time being usable via a pointer and a size variable in the hypervisor.
>
> Make use of that generic tool in xsm.
>
> Signed-off-by: Juergen Gross
>
On 19/02/2020 11:41, Roger Pau Monné wrote:
On Wed, Feb 19, 2020 at 11:35:16AM +, Julien Grall wrote:
Hi Roger,
On 19/02/2020 10:22, Roger Pau Monne wrote:
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the
1 - 100 of 140 matches
Mail list logo
