vcpu_force_reschedule() is only used for modifying the periodic timer
of a vcpu. Forcing a vcpu to give up the physical cpu for that purpose
is kind of brutal.
So instead of doing the reschedule dance just operate on the timer
directly. By protecting periodic timer modifications against concurrent
flight 141294 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141265 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141265/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which did not s
Today a cpu which is removed from the system is taken directly from
Pool0 to the offline state. This will conflict with the new idle
scheduler, so remove it from Pool0 first. Additionally accept removing
a free cpu instead of requiring it to be in Pool0.
For the resume failed case we need to call
Simplify cpupool initialization by populating cpupool0 with cpus only
after all cpus are up. This avoids having to call the cpu notifier
directly for cpu 0.
With that in place there is no need to create cpupool0 earlier, so
do that just before assigning the cpus. Initialize free cpus with all
onli
These three patches have been carved out from my core scheduling series
as they are sufficiently independent to be applied even without the big
series.
Without this little series there are messages like the following to be
seen on the console when booting with smt=0:
(XEN) Adding cpu 1 to runqueu
Instead of having a cpupool_dprintk() define just use debugtrace.
Signed-off-by: Juergen Gross
Acked-by: Dario Faggioli
---
xen/common/cpupool.c | 48 +++-
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/xen/common/cpupool.c b/xen/comm
Instead of having a full blown scheduler running for the free cpus
add a very minimalistic scheduler for that purpose only ever scheduling
the related idle vcpu. This has the big advantage of not needing any
per-cpu, per-domain or per-scheduling unit data for free cpus and in
turn simplifying movin
On 13.09.19 19:27, Dario Faggioli wrote:
On Mon, 2019-09-09 at 11:33 +0200, Juergen Gross wrote:
Today a cpu which is removed from the system is taken directly from
Pool0 to the offline state. This will conflict with the new idle
scheduler, so remove it from Pool0 first. Additionally accept
remo
flight 141288 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141260 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141260/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-i386-qemuu-rhel6hvm-
flight 141264 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141264/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 11 guest-startfail REGR. vs. 141241
test-armhf-armhf-libvir
On Friday, September 13, 2019 5:42 PM, Julien Grall
wrote:
>Hi,
>
>On 9/13/19 8:11 PM, Stewart Hildebrand wrote:
>> Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
>> for Raspberry Pi 4 [1]. Add this string to our platform compatible list
>> for compatibility with the upstr
flight 141286 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
Hi,
On 9/13/19 8:11 PM, Stewart Hildebrand wrote:
Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
for Raspberry Pi 4 [1]. Add this string to our platform compatible list
for compatibility with the upstream kernel.
This raises a few questions:
1) Why such discrepancies
flight 141282 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
The domain builder no longer uses local CPUID instructions for policy
decisions. This resolves a key issue for PVH dom0's. However, as PV dom0's
have never had faulting enforced, leave a command line option to restore the
old behaviour.
Advertise virtualised faulting support to control domains u
flight 141259 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141259/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 140282
test-armhf-armhf-
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
The control domain exclusion for CPUID Faulting predates dom0 PVH, but the
reason for the exclusion (to allow the domain builder to see host CPUID
values) isn't applicable.
The domain builder *is* broken in PVH control domains, and restricting the use
of CPUID Faulting doesn't make it any less bro
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 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
This patch is broken out just to simplify the following two.
For xc_cpuid_set(), document how the 's' and 'k' options works because it is
quite subtle. Replace a memset() with a for loop of 4 explicit NULL
assigments. This mirrors the free()'s in the fail path.
For xc_cpuid_apply_policy(), cons
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 helper will eventually be the core "can a guest configured 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.
This results in better behaviour for the caller.
Suggested-by: Jan Beulich
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* New
---
tools/tests/cpu-policy/test-cpu-policy.c | 4 ++--
xen/include/xen/lib/x86/cpuid.h | 6 +
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
Acked-by: Jan Beulich
---
CC: Jan Beuli
Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
for Raspberry Pi 4 [1]. Add this string to our platform compatible list
for compatibility with the upstream kernel.
[1] https://patchwork.kernel.org/patch/11092621/
Signed-off-by: Stewart Hildebrand
---
xen/arch/arm/platform
On 9/12/19 2:31 PM, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Speci
flight 141258 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-amd64-amd64-xl-
flight 141279 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On Mon, 2019-09-09 at 11:33 +0200, Juergen Gross wrote:
> Today a cpu which is removed from the system is taken directly from
> Pool0 to the offline state. This will conflict with the new idle
> scheduler, so remove it from Pool0 first. Additionally accept
> removing
> a free cpu instead of requiri
On Mon, 2019-09-09 at 11:33 +0200, Juergen Gross wrote:
> Simplify cpupool initialization by populating cpupool0 with cpus only
> after all cpus are up. This avoids having to call the cpu notifier
> directly for cpu 0.
>
> With that in place there is no need to create cpupool0 earlier, so
> do tha
On 9/13/19 3:33 AM, Roger Pau Monné wrote:
> On Thu, Sep 12, 2019 at 11:03:14AM -0700, Joe Jin wrote:
>> With below testcase, guest kernel reported "No irq handler for vector":
>> 1). Passthrough mlx ib VF to 2 pvhvm guests.
>> 2). Start rds-stress between 2 guests.
>> 3). Scale down 2 guests
Hi Jan,
Thanks for your reply, see my reply in line please.
On 9/13/19 12:14 AM, Jan Beulich wrote:
> On 12.09.2019 20:03, Joe Jin wrote:
>> With below testcase, guest kernel reported "No irq handler for vector":
>> 1). Passthrough mlx ib VF to 2 pvhvm guests.
>> 2). Start rds-stress between
On Fri, Sep 13, 2019 at 11:58:26AM +0100, Paul Durrant wrote:
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 12545130df..e4b9c539b6 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -415,6 +415,15 @@
> */
> #define LIBXL_HAVE_BUILDINFO_IOMMU_MEMKB 1
>
> +/*
ERST isn't a mandatory table, and also isn't very common to find. The message
is unnecessary noise during boot. Furthermore, it is redundant with the list
of found ACPI tables printed just ahead.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/drivers/acpi/apei/erst.c | 5 ++---
1 fi
Hi, Juergen
I have just pushed new version, so please update
=== ARM ===
* Renesas IPMMU-VMSA support + Linux's iommu_fwspec (V4)
- Oleksandr Tyshchenko
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject
Printing "$foo disabled" is unnecessary noise during boot. All other VPMU
settings emit a message, so this doesn't result in any ambiguity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/vpmu.c | 3 ---
1 file changed, 3 deletions(-)
di
Message such as:
(XEN) d3v0 VIRIDIAN CRASH: 51 1 9700e146b000 1000 204
have confused many people into thinking the the problem is a bug in the
viridian code. The prefix was intended to signify the use of the viridian
crash-reporting interface.
Replace the VIRIDIAN prefix with 'reported' t
From: Oleksandr Tyshchenko
The main puprose of this patch is to add a way to register DT device
(which is behind the IOMMU) using the generic IOMMU DT bindings [1]
before assigning that device to a domain.
So, this patch adds new "iommu_add_dt_device" API for adding DT device
to the IOMMU using
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
R-Car Gen3 SoCs
From: Oleksandr Tyshchenko
This patch introduces type-unsafe function which besides
re-allocation handles the following corner cases:
1. if requested size is zero, it will behave like xfree
2. if incoming pointer is not valid (NULL or ZERO_BLOCK_PTR),
it will behave like xmalloc
If both point
On Fri, Sep 13, 2019 at 09:21:58AM +0100, Paul Durrant wrote:
> Cleaning up offline 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() i
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT bindings [1] which can be used for
both DT (right now) and ACPI (in future).
For that reason we can borrow the idea used in Linux these days
called "iommu_fwspec". Having thi
From: Oleksandr Tyshchenko
This patch introduces type-safe helper macros to re-allocate space
for a structure with a flexible array of typed objects.
For example, if we need to re-size an array with a single element:
struct arrlen
{
size_t len;
int data[1];
};
We can use t
From: Oleksandr Tyshchenko
Clean up the code a bit by putting the headers in alphabetical order.
Signed-off-by: Oleksandr Tyshchenko
---
xen/drivers/passthrough/arm/iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/arm/iommu.c
b/xen/drive
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.
In order not to pull Linux's error code (-EPROBE_DEFER) to Xen
we have chosen -EAGAIN to be used for indicating t
From: Oleksandr Tyshchenko
The purpose of this patch series is to add IPMMU-VMSA support to Xen on ARM.
Besides new IOMMU driver, this series contains "iommu_fwspec" support
and new API iommu_add_dt_device() for adding DT device to IOMMU and many other
things.
The IPMMU-VMSA is VMSA-compatible
From: Oleksandr Tyshchenko
Introduce a separate file to keep various helpers which could be used
by more than one IOMMU driver in order not to duplicate code.
The first candidates to be moved to the new file are SMMU driver's
"map_page/unmap_page" callbacks. These callbacks neither contain any
S
On Fri, 13 Sep 2019 at 16:28, Wei Liu wrote:
>
> On Fri, 13 Sep 2019 at 13:47, Paul Durrant wrote:
> >
> > My Citrix email address will expire shortly.
> >
> > Signed-off-by: Paul Durrant
>
> Acked-by: Wei Liu
Or rather:
Acked-by: Wei Liu
___
Xen-
On Fri, 13 Sep 2019 at 13:47, Paul Durrant wrote:
>
> My Citrix email address will expire shortly.
>
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
>On Thu, Dec 13, 2018 at 07:54, Chao Gao wrote:
>>On Thu, Dec 13, 2018 at 12:54:52AM -0700, Jan Beulich wrote:
>> On 13.12.18 at 04:46, wrote:
On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
On 12.12
On 13.09.19 16:44, Jan Beulich wrote:
On 13.09.2019 16:07, Juergen Gross wrote:
On 11.09.19 12:30, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -174,6 +174,7 @@ struct vcpu
XEN_GUEST_HANDLE(vcpu_runstate_
XenStoreWaitForEvent is going to be called when the ExitBootServices
is signaled, but both CreateEvent and WaitForEvent can't be used.
CreateEvent allocate some memory and WaitForEvent can only be used
when TPL is TPL_APPLICATION.
When ExitBootServices has been called, simply return immediately an
In order to be able to reset the backend before handing it to the next
operating system, it should be reset properly. This patch register a
callback function to be called by XenBusDxe during the
ExitBootServices event.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony
On 11.09.19 12:43, Jan Beulich wrote:
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?
The problem is the for_each_sched_uni
On 13.09.19 16:42, Jan Beulich wrote:
On 13.09.2019 14:14, Juergen Gross wrote:
---
- Carved out from my core scheduling series
- Reworked to avoid deadlock when 2 vcpus are trying to modify each
others periodic timers, leading to address all comments by Jan
Beulich.
Oh, indeed - a mutua
On 13/09/2019 07:38, Jan Beulich wrote:
>
>> v2:
>> * Introduce a command line option to retain old behaviour.
>> * Advertise virtualised faulting support to dom0 when it is used.
>>
>> RFC: The previous logic was slightly buggy in that even PVH dom0's had
>> virtualised faulting support hidden f
When doing an action with a path and subpath in the xenstore,
XenStoreJoin is called to generate "$path/$subpath". But this function
do an allocation of memory which isn't necessary. Instead we will
construct the path with WRITE_REQUEST and data used to generate the
path will be copied directly to
We will use a buffer on the stack instead of allocating memory for
internal functions that are expecting a reply from xenstore.
The external interface XENBUS_PROTOCOL isn't changed yet, so
allocation are made for XsRead and XsBackendRead.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
S
This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid
using the Memory Allocation Services.
This comes with a new interface named RegisterExitCallback so that PV
drivers can disconnect from the backend before XenBusDxe is teared
down.
Instead of using Disconnect() to tear down the Xen
XsRead and XsBackendRead of the XENBUS_PROTOCOL return allocated
memory but this isn't allowed during the ExitBootServices call. We
need XsRead and XsBackendRead to disconnect from the device so
XENBUS_PROTOCOL is changed to use a buffer supplied by a child driver.
Ref: https://bugzilla.tianocore.
This patch rework XenStoreProcessMessage in order to avoid memory
allocation when a reply is expected. Instead of allocating a buffer
for this reply, we are going to copy to a buffer passed by the caller.
For messages that aren't fully received, they will be stored in a
buffer that have been alloca
Rework XenStoreFindWatch() to be able to search for a registered watch
with a pointer instead of a string.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 20 +++-
1 file changed, 11 insertions(+), 9 deleti
This patch rework the reception of xenstore watch event to avoid
allocation.
Instead of queuing watch events, we simply mark a XENSTORE_WATCH as
"triggered". We don't need to know how many time we received the
event, only that it happened. That avoid to allocate a
XENSTORE_MESSAGE for every watch
Fix missing \n in DEBUG messages in XenBusDxe and use DEBUG_*.
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/EventChannel.c | 3 ++-
OvmfPkg/XenBusDxe/XenStore.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBus
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git
br.xenbusdxe-fix-exitbootservices-v1
Hi,
This patch series works toward removing usage of Memory Allocation Services in
XenBusDxe when Exi
In order to be able to use XenStoreVSPrint during the
ExitBootServices, we remove the allocation done by the function and
use the stack instead.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenBusDxe/XenStore.c | 21 +
1 f
On 13.09.2019 16:07, Juergen Gross wrote:
> On 11.09.19 12:30, Jan Beulich wrote:
>> On 09.08.2019 16:58, Juergen Gross wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -174,6 +174,7 @@ struct vcpu
>>> XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat;
On 13.09.2019 14:14, Juergen Gross wrote:
> ---
> - Carved out from my core scheduling series
> - Reworked to avoid deadlock when 2 vcpus are trying to modify each
> others periodic timers, leading to address all comments by Jan
> Beulich.
Oh, indeed - a mutual vcpu_pause() can't end well.
>
flight 141274 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
> -Original Message-
> From: Roger Pau Monne
> Sent: 13 September 2019 14:54
> To: Jan Beulich
> Cc: Paul Durrant ; xen-devel@lists.xenproject.org;
> Suravee Suthikulpanit
> ; Julien Grall ; Andrew
> Cooper
> ; Anthony Perard ;
> Christian Lindig
> ; George Dunlap ; Ian
> Jackson
> ;
On 12.09.19 12:24, Dario Faggioli wrote:
On Fri, 2019-08-09 at 16:58 +0200, Juergen Gross wrote:
Today the vcpu runstate of a new scheduled vcpu is always set to
"running" even if at that time vcpu_runnable() is already returning
false due to a race (e.g. with pausing the vcpu).
With core sched
On 11.09.19 12:30, Jan Beulich wrote:
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 )
-
flight 141254 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141254/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 141237 REGR. vs. 140844
Tests which are faili
On Fri, Sep 13, 2019 at 01:10:18PM +0200, Jan Beulich wrote:
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -57,7 +57,6 @@ type domain_create_flag =
>| CDF_OOS_OFF
>| CDF_XS_DOMAIN
>| CDF_IOMMU
> -
Stray deletion?
> --- a/xen/include/public/sysctl
On 13.09.2019 13:47, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 13 September 2019 12:10
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Suravee Suthikulpanit ; Julien Grall
>> ; Andrew
>> Cooper ; Anthony Perard
>> ; Christian Lindig
>> ; Roger Pa
> FWIW checked with Ian after I wrote this mail, and he confirmed that
> that field (`link` in `libxl_event`) was only meant to be used
> internally, and ideally we wouldn't even have that available in the Go
> version of the struct (since it's not actually part of the public
> interface).
>
> Unf
On 10.09.19 17:36, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
+static bool sched_tasklet_check(unsigned int cpu)
+{
+bool tasklet_work_scheduled = false;
+const cpumask_t *mask = get_sched_res(cpu)->cpus;
+int cpu_iter;
unsigned int ?
Yes.
+static void conte
On 10.09.19 17:18, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
In order to prepare for multiple vcpus per schedule unit move struct
task_slice in schedule() from the local stack into struct sched_unit
of the currently running unit.
The change looks mechanical enough to be prob
My Citrix email address will expire shortly.
Signed-off-by: Paul Durrant
--
Cc: Wei Liu
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e7a47b5210fd..b36d51f0fe5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17646,7 +17646,7
On 10.09.19 17:11, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -733,35 +733,40 @@ void vcpu_unblock(struct vcpu *v)
}
/*
- * Do the actual movement of a vcpu from old to new CPU. Locks for *both*
+ * Do the actua
flight 141252 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139876
test-amd64-i386-xl
On 12/09/2019 08:22, Chao Gao wrote:
> It ports the implementation of is_blacklisted() in linux kernel
> to Xen.
>
> Late loading may cause system hang if CPUs are affected by BDF90.
> Check against BDF90 before performing a late loading.
>
> Signed-off-by: Chao Gao
There is an Intel-blessed work
vcpu_force_reschedule() is only used for modifying the periodic timer
of a vcpu. Forcing a vcpu to give up the physical cpu for that purpose
is kind of brutal.
So instead of doing the reschedule dance just operate on the timer
directly. By protecting periodic timer modifications against concurrent
> -Original Message-
> From: Jan Beulich
> Sent: 13 September 2019 12:10
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Andrew
> Cooper ; Anthony Perard
> ; Christian Lindig
> ; Roger Pau Monne ; George
> Dunlap
> ; Ian Jackson ; Kevin
flight 141269 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On 9/12/19 6:35 PM, Nicholas Rosbrook wrote:
> I'm not strongly opposed to the struct duplication, but I do prefer the
> ability
> to perform type assertions as a way to determine which field is "valid."
Fair enough.
>> So the advantage of this is that you can just call:
>>
>> fromC(&di, &cd
This patch defines a new bit reported in the hw_cap field of struct
xen_sysctl_physinfo to indicate whether the platform supports sharing of
HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
whether the domain needs extra memory to store discrete IOMMU page tables
or not.
N
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be translate
These are revisions of the remaining uncommitted patches from my
previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html
This series (particlarly patch #6) needs to be applied after:
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg01204.html
t
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set for both dom0 and any domU created by libxl if the IOMMU is
globally enabled (i.e. iommu_enabled == 1). sanitise_domain_config() is
modified to
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
destruction
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed
This patch defines a new bit reported in the hw_cap field of struct
xen_sysctl_physinfo to indicate whether the platform supports sharing of
HAP page tables (i.e. the P2M) with the IOMMU. This informs the toolstack
whether the domain needs extra memory to store discrete IOMMU page tables
or not.
N
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
hard
At the moment, early printk can only be configured on the make command
line. It is not very handy because a user has to remove the option
everytime it is using another command other than compiling the
hypervisor.
Furthermore, early printk is one of the few odds one that are not using
Kconfig.
So
On Thu, Sep 12, 2019 at 11:03:14AM -0700, Joe Jin wrote:
> With below testcase, guest kernel reported "No irq handler for vector":
> 1). Passthrough mlx ib VF to 2 pvhvm guests.
> 2). Start rds-stress between 2 guests.
> 3). Scale down 2 guests vcpu from 32 to 6 at the same time.
>
> Repeat
1 - 100 of 131 matches
Mail list logo
