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 2 guests.
> 3). Scale down 2 guests vcpu from 32 to 6 at the same time.
>
> Repeat above test several it
On 13.09.2019 09:01, Chao Gao wrote:
> On Thu, Sep 12, 2019 at 05:32:22PM +0200, Jan Beulich wrote:
>> On 12.09.2019 09:22, Chao Gao wrote:
>>> +static int secondary_thread_fn(void)
>>> +{
>>> +unsigned int primary = cpumask_first(this_cpu(cpu_sibling_mask));
>>> +
>>> +if ( !wait_for_state
flight 141263 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141263/
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: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 12 September 2019 16:16
> To: Anthony Perard
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; qemu-de...@nongnu.org
> Subject: Re: [Xen-devel] [PATCH v2 3/3] xen: perform XenDevice clean-up in
> XenB
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() is insufficient as *two* notifiers (for
the frontend and backend watche
Xenstore watch call-backs are already abstracted away from XenBus using
the XenWatch data structure but the associated NotifierList manipulation
and file handle registration is still open coded in various xen_bus_...()
functions.
This patch creates a new XenWatchList data structure to allow these
i
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
Reviewed-by: Anthony Perard
---
Cc:
Hi Jan,
On 13/09/2019 07:13, Jan Beulich wrote:
On 13.09.2019 07:44, Juergen Gross wrote:
Add missing #includes.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Albeit for the future it would be nice if the connection to the
actual breakage was established in the description, by mentio
On 12.09.2019 09:22, Chao Gao wrote:
> This series includes below changes:
> 1. Patch 1-11: introduce a global microcode cache and some cleanup
> 2. Patch 12: synchronize late microcode loading
> 3. Patch 13: support parallel microcodes update on different cores
> 4. Patch 14: block #NMI handli
On 12.09.2019 09:22, Chao Gao wrote:
> When one core is loading ucode, handling NMI on sibling threads or
> on other cores in the system might be problematic. By rendezvousing
> all CPUs in NMI handler, it prevents NMI acceptance during ucode
> loading.
>
> Basically, some work previously done in
On 12.09.2019 09:22, Chao Gao wrote:
> @@ -419,14 +465,23 @@ static int control_thread_fn(const struct
> microcode_patch *patch)
> return ret;
> }
>
> -/* Let primary threads load the given ucode update */
> -set_state(LOADING_ENTER);
> -
> +/* Control thread loads ucod
On 12.09.2019 09:22, Chao Gao wrote:
> @@ -283,6 +284,27 @@ static enum microcode_match_result compare_patch(
> : OLD_UCODE;
> }
>
> +static bool is_blacklisted(void)
> +{
> +struct cpuinfo_x86 *c = ¤t_cpu_data;
> +uint64_t ll
On 12.09.2019 09:22, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -305,6 +305,31 @@ static bool is_blacklisted(void)
> return false;
> }
>
> +static void microcode_quirk(void)
> +{
> +struct cpuinfo_x86 *c;
const
> +uint64_t ll
On 10.09.19 16:06, Jan Beulich wrote:
On 09.08.2019 16:58, Juergen Gross wrote:
vcpu_force_reschedule() is only used for modifying the periodic timer
of a vcpu.
I don't think this is true prior to this patch, or else ...
@@ -419,8 +419,6 @@ int pv_shim_shutdown(uint8_t reason)
i
On 13.09.2019 11:33, Juergen Gross wrote:
> On 10.09.19 16:06, Jan Beulich wrote:
>> On 09.08.2019 16:58, Juergen Gross wrote:
>>> vcpu_force_reschedule() is only used for modifying the periodic timer
>>> of a vcpu.
>>
>> I don't think this is true prior to this patch, or else ...
>>
>>> @@ -419,8
These are revisions of the remaining uncommitted patches from my
previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html
Paul Durrant (6):
domain: introduce XEN_DOMCTL_CDF_iommu flag
use is_iommu_enabled() where appropriate...
sysctl / libxl: report wheth
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
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
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
...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
...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
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
On 12.09.2019 15:28, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -348,6 +348,7 @@ static s_time_t lock_profile_start;
> static struct lock_profile_anc *lock_profile_ancs;
> static struct lock_profile_qhead lock_profile_glb_q;
> static spinlock_t lock_pro
On 8/21/19 11:04 AM, Pawel Wieczorkiewicz wrote:
This complements [1] commit for ARM and livepatch_elf files.
[1] 4470efeae4 livepatch: always print XENLOG_ERR information
Signed-off-by: Pawel Wieczorkiewicz
---
xen/arch/arm/arm32/livepatch.c | 28 +--
xen/arch/arm/arm64/livepatch.
On 13.09.2019 11:47, Paul Durrant wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -56,8 +56,10 @@ extern bool_t iommu_enable, iommu_enabled;
> extern bool_t force_iommu, iommu_verbose, iommu_igfx;
> extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost
> -Original Message-
> From: Jan Beulich
> Sent: 13 September 2019 11:05
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
On 13.09.19 11:53, Jan Beulich wrote:
On 12.09.2019 15:28, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -348,6 +348,7 @@ static s_time_t lock_profile_start;
static struct lock_profile_anc *lock_profile_ancs;
static struct lock_profile_qhead lock_profile_glb
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.18 at 16:18, wrote:
> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan
If the end of one enum is the `type' line for the next enum, we would
not notice it.
Fix this by reordering the code, and getting rid of the else: now if
the "we are within an enum" branch decides that it's the end of the
enum, it unsets $ei and we then immediately process the line as a "not
withi
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
> -Original Message-
> From: Jan Beulich
> Sent: 13 September 2019 11:05
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
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
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
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
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
...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
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
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
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
> -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
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
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
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 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
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: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
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
> 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 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
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
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 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 )
-
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
> -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
> ;
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
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.
>
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;
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
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
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
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
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.
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
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
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
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 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
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
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
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_
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 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, 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-
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
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
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 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
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-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
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
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
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
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
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
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
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
>
> +/*
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 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
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 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
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
1 - 100 of 131 matches
Mail list logo
