On 30.11.2020 18:39, Diederik de Haas wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -680,7 +680,7 @@ static void pvpmu_finish(struct domain *d,
> xen_pmu_params_t *params)
> vcpu_unpause(v);
> }
>
> -/* Dump some vpmu informations on console. Used in keyha
On Tue, Dec 01, 2020 at 12:52:27AM -0500, Martin K. Petersen wrote:
>
> Gustavo,
>
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
>
> Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks.
Awesome! :)
Thanks, Mart
When a cpu is removed from a cpupool and added to the free cpus it
should be added to sched_res_mask, too.
The related removal from sched_res_mask in case of core scheduling
is already done in schedule_cpu_add().
As long as all cpupools share the same scheduling granularity there
is nothing going
Common style is to include header files in alphabetical order. Sort the
#include statements in cpupool.c accordingly.
Signed-off-by: Juergen Gross
Acked-by: Dario Faggioli
---
xen/common/sched/cpupool.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched
The cpupool id is an unsigned value in the public interface header, so
there is no reason why it is a signed value in struct cpupool.
Switch it to unsigned int.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/common/sched/core.c| 2 +-
xen/common/sched/cpupool.c | 48 +
Support scheduling granularity per cpupool. Setting the granularity is
done via hypfs, which needed to gain dynamical entries for that
purpose.
Apart from the hypfs related additional functionality the main change
for cpupools was the support for moving a domain to a new granularity,
as this requi
The /params/* entry is missing a writable tag.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
docs/misc/hypfs-paths.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index dddb592bc5..6c7b2f7ee3 100644
Even with storing the scheduling granularity in struct cpupool there
are still a few bits missing for being able to have cpupools with
different granularity (apart from the missing interface for setting
the individual granularities): the number of cpus in a scheduling
unit is always taken from the
Instead of a pointer to an error variable as parameter just use
ERR_PTR() to return the cause of an error in cpupool_create().
This propagates to scheduler_alloc(), too.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/common/sched/core.c| 13 ++---
xen/common/sched/cpupool.
Instead of open coding something like a linked list just use the
available functionality from list.h.
The allocation of a new cpupool id is not aware of a possible wrap.
Fix that.
While adding the required new include to private.h sort the includes.
Signed-off-by: From: Juergen Gross
---
V2:
-
Move the function pointers currently stored in each hypfs node into a
dedicated structure in order to save some space for each node. This
will save even more space with additional callbacks added in future.
Provide some standard function vectors.
Instead of testing the write pointer to be not NUL
When moving a domain between cpupools with different scheduling
granularity the sched_units of the domain need to be adjusted.
Do that by allocating new sched_units and throwing away the old ones
in sched_move_domain().
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 121
Add a "sched-gran" entry to the per-cpupool hypfs directories.
For now make this entry read-only and let it contain one of the
strings "cpu", "core" or "socket".
Signed-off-by: Juergen Gross
---
V2:
- added const (Jan Beulich)
- modify test in cpupool_gran_read() (Jan Beulich)
---
docs/misc/hyp
Instead of handling all errors from hypfs_get_entry() as ENOENT pass
up the real error value via ERR_PTR().
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
xen/common/hypfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/common/hypfs.c b/xen/comm
Add a getsize() function pointer to struct hypfs_funcs for being able
to have dynamically filled entries without the need to take the hypfs
lock each time the contents are being generated.
For directories add a findentry callback to the vector and modify
hypfs_get_entry_rel() to use it.
Signed-of
Add a HYPFS_VARDIR_INIT() macro for initializing such a directory
statically, taking a struct hypfs_funcs pointer as parameter additional
to those of HYPFS_DIR_INIT().
Modify HYPFS_VARSIZE_INIT() to take the function vector pointer as an
additional parameter as this will be needed for dynamical en
Make /cpupool//sched-gran in hypfs writable. This will enable per
cpupool selectable scheduling granularity.
Writing this node is allowed only with no cpu assigned to the cpupool.
Allowed are values "cpu", "core" and "socket".
Signed-off-by: Juergen Gross
---
V2:
- test user parameters earlier (
In order to better support resource allocation and locking for dynamic
hypfs nodes add enter() and exit() callbacks to struct hypfs_funcs.
The enter() callback is called when entering a node during hypfs user
actions (traversing, reading or writing it), while the exit() callback
is called when lea
Add some helpers to hypfs.c to support dynamic directories with a
numerical id as name.
The dynamic directory is based on a template specified by the user
allowing to use specific access functions and having a predefined
set of entries in the directory.
Signed-off-by: Juergen Gross
---
V2:
- use
Add /cpupool/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
V2:
- added const (Jan Beulich)
- call hypfs_add_dir() in helper (Dario Faggioli)
- switch locking to enter/exit callbacks
---
docs/mis
flight 157125 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 157116 qemu-mainline real [real]
flight 157127 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157116/
http://logs.test-lab.xenproject.org/osstest/logs/157127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 01.12.2020 09:21, Juergen Gross wrote:
> @@ -243,11 +243,11 @@ void cpupool_put(struct cpupool *pool)
> * - unknown scheduler
> */
> static struct cpupool *cpupool_create(
> -int poolid, unsigned int sched_id, int *perr)
> +unsigned int poolid, unsigned int sched_id, int *perr)
> {
On 01.12.2020 09:21, Juergen Gross wrote:
> Add /cpupool/ directories to hypfs. Those are completely
> dynamic, so the related hypfs access functions need to be implemented.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - added const (Jan Beulich)
Any particular reason this doesn't extend to ..
On 01.12.20 09:55, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -243,11 +243,11 @@ void cpupool_put(struct cpupool *pool)
* - unknown scheduler
*/
static struct cpupool *cpupool_create(
-int poolid, unsigned int sched_id, int *perr)
+unsigned int poolid, unsign
On 01.12.20 10:00, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
Add /cpupool/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
V2:
- added const (Jan Beulich)
Any particular reas
On 01.12.2020 10:01, Jürgen Groß wrote:
> On 01.12.20 09:55, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> @@ -243,11 +243,11 @@ void cpupool_put(struct cpupool *pool)
>>>* - unknown scheduler
>>>*/
>>> static struct cpupool *cpupool_create(
>>> -int poolid, unsi
On 01.12.2020 09:21, Juergen Gross wrote:
> @@ -260,23 +257,42 @@ static struct cpupool *cpupool_create(
>
> spin_lock(&cpupool_lock);
>
> -for_each_cpupool(q)
> +if ( poolid != CPUPOOLID_NONE )
> {
> -last = (*q)->cpupool_id;
> -if ( (poolid != CPUPOOLID_NONE)
On 01.12.20 10:12, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -260,23 +257,42 @@ static struct cpupool *cpupool_create(
spin_lock(&cpupool_lock);
-for_each_cpupool(q)
+if ( poolid != CPUPOOLID_NONE )
{
-last = (*q)->cpupool_id;
-if
flight 157119 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 30/11/2020 23:27, Oleksandr wrote:
On 30.11.20 23:03, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put th
Hi Jan,
On 01/12/2020 07:55, Jan Beulich wrote:
On 01.12.2020 00:27, Oleksandr wrote:
On 30.11.20 23:03, Volodymyr Babchuk wrote:
Oleksandr Tyshchenko writes:
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -83,6 +83,30 @@ static inline bool VABORT_GEN_BY_GUEST(const st
On 01.12.20 12:30, Julien Grall wrote:
Hi Julien
Hi Jan,
On 01/12/2020 07:55, Jan Beulich wrote:
On 01.12.2020 00:27, Oleksandr wrote:
On 30.11.20 23:03, Volodymyr Babchuk wrote:
Oleksandr Tyshchenko writes:
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -83,6 +83
On 01.12.2020 11:30, Julien Grall wrote:
> Hi Jan,
>
> On 01/12/2020 07:55, Jan Beulich wrote:
>> On 01.12.2020 00:27, Oleksandr wrote:
>>> On 30.11.20 23:03, Volodymyr Babchuk wrote:
Oleksandr Tyshchenko writes:
> --- a/xen/include/asm-arm/traps.h
> +++ b/xen/include/asm-arm/traps.h
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> As a lot of x86 code can be re-used on Arm later on, this
> patch makes some preparation to x86/hvm/ioreq.c before moving
> to the common code. This way we will get a verbatim copy
>
> It worth mentioning that a code which checks t
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> This patch continues to make some preparation to x86/hvm/ioreq.c
> before moving to the common code.
>
> Add IOREQ_STATUS_* #define-s and update candidates for moving
> since X86EMUL_* shouldn't be exposed to the common code in
> th
Hi Volodymyr,
> On 30 Nov 2020, at 20:15, Volodymyr Babchuk
> wrote:
>
>
> Bertrand Marquis writes:
>
>> Create a cpuinfo structure for guest and mask into it the features that
>> we do not support in Xen or that we do not want to publish to guests.
>>
>> Modify some values in the cpuinfo st
Hi Volodymyr,
> On 30 Nov 2020, at 20:22, Volodymyr Babchuk
> wrote:
>
>
>
> Bertrand Marquis writes:
>
>> Add vsysreg emulation for registers trapped when TID3 bit is activated
>> in HSR.
>> The emulation is returning the value stored in cpuinfo_guest structure
>> for most values and the ha
Hi,
> On 30 Nov 2020, at 20:31, Volodymyr Babchuk
> wrote:
>
>
> Bertrand Marquis writes:
>
>> Add support for emulation of cp15 based ID registers (on arm32 or when
>> running a 32bit guest on arm64).
>> The handlers are returning the values stored in the guest_cpuinfo
>> structure.
>> In th
Hi Bertrand,
Bertrand Marquis writes:
> Hi Volodymyr,
>
>> On 30 Nov 2020, at 20:22, Volodymyr Babchuk
>> wrote:
>>
>>
>>
>> Bertrand Marquis writes:
>>
>>> Add vsysreg emulation for registers trapped when TID3 bit is activated
>>> in HSR.
>>> The emulation is returning the value stored i
Hi,
Bertrand Marquis writes:
> Hi,
>
>> On 30 Nov 2020, at 20:31, Volodymyr Babchuk
>> wrote:
>>
>>
>> Bertrand Marquis writes:
>>
>>> Add support for emulation of cp15 based ID registers (on arm32 or when
>>> running a 32bit guest on arm64).
>>> The handlers are returning the values stored
Hi Oleksandr,
On 01/12/2020 10:42, Oleksandr wrote:
On 01.12.20 12:30, Julien Grall wrote:
Hi Julien
Hi Jan,
On 01/12/2020 07:55, Jan Beulich wrote:
On 01.12.2020 00:27, Oleksandr wrote:
On 30.11.20 23:03, Volodymyr Babchuk wrote:
Oleksandr Tyshchenko writes:
--- a/xen/include/asm-arm/t
Hello,
According to this news
(https://aws.amazon.com/blogs/aws/new-use-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/),
Amazon EC2 can run macOS.
Is it OK for Xen Project too?
Thanks.
On 01.12.20 14:13, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -83,6 +83,30 @@ static inline bool VABORT_GEN_BY_GUEST(const
struct cpu_user_regs *regs)
(unsigned long)abort_guest_exit_end == regs->pc;
On 01/12/2020 12:24, Oleksandr wrote:
On 01.12.20 14:13, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -83,6 +83,30 @@ static inline bool VABORT_GEN_BY_GUEST(const
struct cpu_user_regs *regs)
(unsigned
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> The seemingly arbitrary use of 'pci' and 'pcidev' in the code in libxl_pci.c
> is confusing and also compromises use of some macros used for other device
> types. Indeed it seems that DEFINE_DEVICE_TYPE_STRUCT_X exists s
Hi Volodymyr,
On 30/11/2020 20:51, Volodymyr Babchuk wrote:
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
This patch adds proper handling of return value of
vcpu_ioreq_handle_completion() which involves using a loop
in leave_hypervisor_to_guest().
The reason to use an unbounded lo
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> ... devices.
>
> Currently there is an assumption built into libxl__device_list() that device
> backends are fully enumarated under the '/libxl' path in xenstore. This is
> not the case for PCI backend devices, which are
flight 157123 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157123/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail in
157115 pass in 157123
test-armhf-ar
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently libxl__device_pci_add_xenstore() is broken in that does not
> update the domain's configuration for the first device added (which causes
> creation of the overall backend area in xenstore). This can be easily o
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> Other parameters, such as 'msitranslate' and 'permissive' are dealt with
> but 'rdm_policy' appears to be have been completely missed.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
From: Paul Durrant
Simply spelling correction. Purely cosmetic fix.
Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 22 +
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> Both 'domid' and 'pci' are available in 'pci_remove_state' so there is no
> need to also pass them as separate arguments.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
>
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to hold a pointer to the device.
>
> There is already a 'pci' field in 'pci_add_state' so simply use that from
> the start. This also allows the 'pci' (#3) argument to be dropped from
> do_pci_add().
>
> NOTE: This p
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> For the purposes of re-binding a device to its previous driver
> libxl__device_pci_assignable_add() writes the driver path into xenstore.
> This path is then read back in libxl__device_pci_assignable_remove().
>
> The fu
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> The code currently checks explicitly whether the device is already assigned,
> but this is actually unnecessary as assigned devices do not form part of
> the list returned by libxl_device_pci_assignable_list() and hence
Hi,
> On 30 Nov 2020, at 20:39, Volodymyr Babchuk
> wrote:
>
>
> Bertrand Marquis writes:
>
>> Add support for cp10 exceptions decoding to be able to emulate the
>> values for VMFR0 and VMFR1 when TID3 bit of HSR is activated.
>> This is required for aarch32 guests accessing VMFR0 and VMFR1 u
On Sun, Nov 22, 2020 at 08:17:03AM -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gusta
Wei,
I'll likely send a v4 to address the style nit Jan picked up in patch #1 but
the rest should be stable now. Could you have a look over it?
Thanks,
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 24 November 2020 19:08
> To: xen-devel@lists.xenproject.org
> Cc: Durr
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it so
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> Use of this function is a very inefficient way to check whether a device
> has already been assigned.
>
> This patch adds code that saves the domain id in xenstore at the point of
> assignment, and removes it again when
Hi Volodymyr,
> On 1 Dec 2020, at 12:07, Volodymyr Babchuk wrote:
>
>
> Hi,
>
> Bertrand Marquis writes:
>
>> Hi,
>>
>>> On 30 Nov 2020, at 20:31, Volodymyr Babchuk
>>> wrote:
>>>
>>>
>>> Bertrand Marquis writes:
>>>
Add support for emulation of cp15 based ID registers (on arm32 or
Only spelling errors; no functional changes.
In docs/misc/dump-core-format.txt there are a few more instances of
'informations'. I'll leave that up to someone who can properly determine
how those sentences should be constructed.
Signed-off-by: Diederik de Haas
---
I incorporated the remarks by
On 01.12.2020 15:42, Diederik de Haas wrote:
> Only spelling errors; no functional changes.
>
> In docs/misc/dump-core-format.txt there are a few more instances of
> 'informations'. I'll leave that up to someone who can properly determine
> how those sentences should be constructed.
>
> Signed-of
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> A previous patch introduced libxl_device_pci_list_free() which should be used
> by callers of libxl_device_pci_list() to properly dispose of the exported
> 'libxl_device_pci' types and the free the memory holding them. W
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to be used by callers of libxl_device_pci_assignable_list().
>
> Currently there is no API for callers of libxl_device_pci_assignable_list()
> to free the list. The xl function pciassignable_list() calls
> libxl_devi
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> ... rather than an open-coded equivalent.
>
> This patch tidies up the is_pci_in_array() function, making it take a single
> 'libxl_device_pci' argument rather than separate domain, bus, device and
> function arguments.
On dinsdag 1 december 2020 16:10:13 CET Jan Beulich wrote:
> I'm afraid this isn't the kind of change we'd be backporting,
Ok, I didn't know that.
> unless you have a very good justification for a respective request.
I was fixing issues found by Debian's lintian tool and 4.14 is currently in
Hi, Paul!
On 11/24/20 10:01 AM, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and put it into a new xl-pci-configuration(5) manpage, akin to the
> xl-network-configration(5) and xl-disk-configuration(5) manpages.
>
> This patch moves the content of the section verbatim. A subsequent patch
> wi
Hi,
Bertrand Marquis writes:
> Hi Volodymyr,
>
>> On 1 Dec 2020, at 12:07, Volodymyr Babchuk
>> wrote:
>>
>>
>> Hi,
>>
>> Bertrand Marquis writes:
>>
>>> Hi,
>>>
On 30 Nov 2020, at 20:31, Volodymyr Babchuk
wrote:
Bertrand Marquis writes:
> Add suppor
Do not attempt to mask an MSI-X entry if MSI-X is not enabled. Else it
will lead to hitting the following assert on debug builds:
(XEN) Panic on CPU 13:
(XEN) Assertion 'entry->arch.pirq != INVALID_PIRQ' failed at vmsi.c:843
In order to fix it exit early from the switch in msix_write if MSI-X
is
On 01.12.20 13:03, Alex Bennée wrote:
Hi Alex
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy
It wor
Oleksandr writes:
> On 01.12.20 13:03, Alex Bennée wrote:
>
> Hi Alex
>
>> Oleksandr Tyshchenko writes:
>>
>>> From: Oleksandr Tyshchenko
>>>
>>> As a lot of x86 code can be re-used on Arm later on, this
>>> patch makes some preparation to x86/hvm/ioreq.c before moving
>>> to the common code.
flight 157129 qemu-mainline real [real]
flight 157140 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157129/
http://logs.test-lab.xenproject.org/osstest/logs/157140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 157131 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-amd64-i386-qemut-rhel6hvm-intel 7 xe
On Thu, 26 Nov 2020, Rahul Singh wrote:
> Based on tag Linux 5.9.8 commit 951cbbc386ff01b50da4f46387e994e81d9ab431
>
> It's a copy of the Linux SMMUv3 driver. Xen specific code has not
> been added yet and code has not been compiled.
>
> Signed-off-by: Rahul Singh
Acked-by: Stefano Stabellini
On Thu, 26 Nov 2020, Rahul Singh wrote:
> Linux SMMUv3 code implements the commands-queue insertion based on
> atomic operations implemented in Linux. Atomic functions used by the
> commands-queue insertion is not implemented in XEN therefore revert the
> patch that implemented the commands-queue i
On Thu, 26 Nov 2020, Rahul Singh wrote:
> XArray is not implemented in XEN revert the patch that introduce the
> XArray code in SMMUv3 driver.
>
> Once XArray is implemented in XEN this patch can be added in XEN.
>
> Reverted the commit 0299a1a81ca056e79c1a7fb751f936ec0d5c7afe
>
> Signed-off-by:
On Thu, 26 Nov 2020, Rahul Singh wrote:
> XEN does not support MSI on ARM platforms, therefore remove the MSI
> support from SMMUv3 driver.
>
> Signed-off-by: Rahul Singh
I wonder if it makes sense to #ifdef CONFIG_MSI this code instead of
removing it completely.
In the past, we tried to keep
On Thu, 26 Nov 2020, Rahul Singh wrote:
> PCI ATS functionality is not implemented and tested on ARM. Remove the
> PCI ATS support, once PCI ATS support is tested and available this
> patch can be added.
>
> Signed-off-by: Rahul Singh
This looks like a revert of 9ce27afc0830f. Can we add that as
On Tue, 1 Dec 2020, Stefano Stabellini wrote:
> On Thu, 26 Nov 2020, Rahul Singh wrote:
> > XEN does not support MSI on ARM platforms, therefore remove the MSI
> > support from SMMUv3 driver.
> >
> > Signed-off-by: Rahul Singh
>
> I wonder if it makes sense to #ifdef CONFIG_MSI this code instead
flight 157133 xen-4.14-testing real [real]
flight 157144 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157133/
http://logs.test-lab.xenproject.org/osstest/logs/157144/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Thu, 26 Nov 2020, Rahul Singh wrote:
> Linux SMMUv3 driver supports both Stage-1 and Stage-2 translations.
> As of now only Stage-2 translation support has been tested.
>
> Once Stage-1 translation support is tested this patch can be added.
>
> Signed-off-by: Rahul Singh
[...]
> @@ -1871,1
On Thu, 26 Nov 2020, Rahul Singh wrote:
> struct io_pgtable_ops, struct io_pgtable_cfg, struct iommu_flush_ops,
> and struct iommu_ops related code are linux specific.
>
> Remove code related to above struct as code is dead code in XEN.
There are still instances of struct io_pgtable_cfg after app
On Tue, Dec 1, 2020 at 4:22 AM Jason Long wrote:
>
> Hello,
> According to this news
> (https://aws.amazon.com/blogs/aws/new-use-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/),
> Amazon EC2 can run macOS.
> Is it OK for Xen Project too?
Amazon recently clarified that these
On Thu, 26 Nov 2020, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementation. It is based on
> the Linux SMMUv3 driver.
>
> Major differences with regard to Linux driver are as follows:
> 1. Only Stage-2 translation is supported as compared to the Linux driver
>that supports
flight 157134 xen-4.12-testing real [real]
flight 157148 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157134/
http://logs.test-lab.xenproject.org/osstest/logs/157148/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 20.11.20 16:33, Jürgen Groß wrote:
On 11.11.20 11:01, Juergen Gross wrote:
A guest with memory < maxmem often can't be dumped via xl dump-core
without an error message today:
xc: info: exceeded nr_pages (262144) losing pages
In case the last page of the guest isn't allocated the loop in
xc_
evtchn_fifo_set_pending() can be simplified a little bit. Especially
testing for the fifo control block to exist can be moved out of the
main if clause of the function enabling to avoid testing the LINKED bit
twice.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V8:
- new patch
V9:
flight 157135 xen-4.13-testing real [real]
flight 157152 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157135/
http://logs.test-lab.xenproject.org/osstest/logs/157152/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
90 matches
Mail list logo
