On 02.12.2020 16:51, Jürgen Groß wrote:
> On 02.12.20 16:42, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> 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 con
On 02.12.2020 17:34, Igor Druzhinin wrote:
> On 02/12/2020 15:21, Jan Beulich wrote:
>> On 02.12.2020 15:53, Igor Druzhinin wrote:
>>> On 02/12/2020 09:25, Jan Beulich wrote:
Instead I'm wondering whether this wouldn't better be a Kconfig
setting (or even command line controllable). There
On 03.12.2020 02:58, Igor Druzhinin wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1641,6 +1641,15 @@ This option is ignored in **pv-shim** mode.
> ### nr_irqs (x86)
> > `= `
>
> +### irq_max_guests (x86)
As a rule of thumb, new options want to
On 02.12.20 16:36, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
static int hypfs_write(struct hypfs_entry *entry,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
As a tangent, is there a reason these write functions don't take
handles of "cons
On 03.12.2020 02:58, Igor Druzhinin wrote:
> @@ -1540,6 +1540,7 @@ int pirq_guest_bind(struct vcpu *v, struct pirq *pirq,
> int will_share)
> unsigned intirq;
> struct irq_desc *desc;
> irq_guest_action_t *action, *newaction = NULL;
> +unsigned intmax_nr_
On 03.12.2020 02:58, Igor Druzhinin wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1641,6 +1641,15 @@ This option is ignored in **pv-shim** mode.
> ### nr_irqs (x86)
> > `= `
>
> +### irq_max_guests (x86)
> +> `= `
> +
> +> Default: `16`
> +
> +
flight 157164 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
test-amd64-i386-qemut-rhel6hvm-intel 7 xe
On 03.12.2020 09:47, Jürgen Groß wrote:
> On 02.12.20 16:36, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> static int hypfs_write(struct hypfs_entry *entry,
>>> XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>
>> As a tangent, is there
flight 157171 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157171/
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
On 02.12.2020 18:14, Julien Grall wrote:
> Hi Jan,
>
> On 02/12/2020 14:49, Jan Beulich wrote:
>> Doing so limits what can be done in (in particular included by) this per-
>> arch header. Abstract out page shift/size related #define-s, which is all
>> the repsecitve headers care about. Extend the
On 03.12.20 09:12, Jan Beulich wrote:
On 02.12.2020 16:51, Jürgen Groß wrote:
On 02.12.20 16:42, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
Add a getsize() function pointer to struct hypfs_funcs for being able
to have dynamically filled entries without the need to take the hy
On 02.12.2020 18:35, Julien Grall wrote:
> On 02/12/2020 14:50, Jan Beulich wrote:
>> xen/mm.h has heavy dependencies, while in a number of cases only these
>> type definitions are needed. This separation then also allows pulling in
>> these definitions when including xen/mm.h would cause cyclic
>>
On 02.12.2020 20:03, Julien Grall wrote:
> On 23/11/2020 13:28, Jan Beulich wrote:
>> The per-vCPU virq_lock, which is being held anyway, together with there
>> not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
>> is zero, provide sufficient guarantees.
>
> I agree that the
On 03.12.20 10:12, Jan Beulich wrote:
On 03.12.2020 09:47, Jürgen Groß wrote:
On 02.12.20 16:36, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
static int hypfs_write(struct hypfs_entry *entry,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
ulen)
On 02.12.2020 22:10, Julien Grall wrote:
> On 23/11/2020 13:30, Jan Beulich wrote:
>> While there don't look to be any problems with this right now, the lock
>> order implications from holding the lock can be very difficult to follow
>> (and may be easy to violate unknowingly). The present callback
From: Hongyan Xia
There is simply no guarantee that vmap won't return superpages to the
caller. It can happen if the list of MFNs are contiguous, or we simply
have a large granularity. Although rare, if such things do happen, we
will simply hit BUG_ON() and crash.
Introduce xen_map_to_mfn() to t
Apologies. Missing v2 in the title.
Hello Julien,
Thanks for reviewing the code.
> On 2 Dec 2020, at 1:44 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 26/11/2020 17:02, Rahul Singh wrote:
>> Linux SMMUv3 code implements the commands-queue insertion based on
>> atomic operations implemented in Linux. Atomic functions used by the
On 03/12/2020 09:27, Jan Beulich wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-arm/page-shift.h
>> The name of the file looks a bit odd given that *_BITS are also defined
>> in it. So how about renaming to page-size.h?
> I was initially meaning to use that name, but these headers
> specifical
flight 157167 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157167/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c4ab1c2ef60a4690177d2361f8dd44d7d7df7f8
baseline version:
ovmf 9fb629edd75e1ae1e7f4e
From: Paul Durrant
...to control the visibility of the FIFO event channel operations
(EVTCHNOP_init_control, EVTCHNOP_expand_array, and EVTCHNOP_set_priority) to
the guest.
These operations were added to the public header in commit d2d50c2f308f
("evtchn: add FIFO-based event channel ABI") and th
From: Paul Durrant
This series was previously called "evtchn: Introduce a per-guest knob to
control FIFO ABI". It is been extensively re-worked and extended to cover
another ABI feature.
Paul Durrant (4):
domctl: introduce a new domain create flag,
XEN_DOMCTL_CDF_evtchn_fifo, ...
domctl:
From: Paul Durrant
... to control which features of the Xen ABI are enabled in
'libxl_domain_build_info', and hence exposed to the guest.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
v5:
- New in v5
---
docs/man/xl.cfg.5.pod.in | 50 ++
From: Paul Durrant
...to control the visibility of the per-vCPU upcall feature for HVM guests.
Commit 04447f4453c0 ("x86/hvm: add per-vcpu evtchn upcalls") added a mechanism
by which x86 HVM guests can register a vector for each vCPU which will be used
by Xen to signal event channels on that vCP
From: Paul Durrant
... and bitmaps to enable or disable fetaures.
This patch adds a new 'libxl_xen_abi_features' enumeration into the IDL which
specifies features of the Xen ABI which may be optionally enabled or disabled
via new 'feature_enable' and 'feature_disable' bitaps added into
'libxl_do
Hello Julien,
> On 2 Dec 2020, at 1:46 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 26/11/2020 17:02, Rahul Singh wrote:
>> XArray is not implemented in XEN revert the patch that introduce the
>> XArray code in SMMUv3 driver.
>
> Similar to the atomic revert, you are explaining why the revert
Hello Julien,
> On 2 Dec 2020, at 2:11 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 02/12/2020 13:12, Rahul Singh wrote:
>> Hello Stefano,
>>> On 2 Dec 2020, at 12:40 am, Stefano Stabellini
>>> wrote:
>>>
>>> On Tue, 1 Dec 2020, Stefano Stabellini wrote:
On Thu, 26 Nov 2020, Rahul Singh
> -Original Message-
> From: Oleksandr Andrushchenko
> Sent: 01 December 2020 12:33
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Ian Jackson ;
> Wei Liu ;
> Anthony PERARD
> Subject: Re: [PATCH v4 01/23] xl / libxl: s/pcidev/pci and remove
> DEFINE_DEVICE_TYP
On 03.12.20 13:41, Paul Durrant wrote:
From: Paul Durrant
This series was previously called "evtchn: Introduce a per-guest knob to
control FIFO ABI". It is been extensively re-worked and extended to cover
another ABI feature.
Paul Durrant (4):
domctl: introduce a new domain create flag,
> -Original Message-
> From: Oleksandr Andrushchenko
> Sent: 01 December 2020 13:12
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Ian Jackson ;
> Wei Liu ;
> Anthony PERARD
> Subject: Re: [PATCH v4 03/23] libxl: Make sure devices added by pci-attach
> are refl
On 12/3/20 3:17 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Oleksandr Andrushchenko
>> Sent: 01 December 2020 13:12
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Paul Durrant ; Ian Jackson ;
>> Wei Liu ;
>> Anthony PERARD
>> Subject: Re: [PATCH v4 03/23] libxl:
Acked-by: Christian Lindig
From: Jürgen Groß
Sent: Thursday, December 03, 2020 13:15
To: Paul Durrant; xen-devel@lists.xenproject.org
Cc: Paul Durrant; Andrew Cooper; Anthony Perard; Christian Lindig; David Scott;
George Dunlap; Ian Jackson; Jan Beulich; Julien
On 02.12.2020 09:38, Jan Beulich wrote:
> On 01.12.2020 18:40, Roger Pau Monne wrote:
>> --- a/xen/drivers/vpci/msix.c
>> +++ b/xen/drivers/vpci/msix.c
>> @@ -357,7 +357,11 @@ static int msix_write(struct vcpu *v, unsigned long
>> addr, unsigned int len,
>> * so that it picks the new sta
> -Original Message-
> From: Jürgen Groß
> Sent: 03 December 2020 13:15
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; Anthony PERARD
> ; Christian Lindig ;
> David Scott
> ; George Dunlap ; Ian Jackson
> ; Jan
> Beulich ; Julien Grall ; Roger
On 03.12.20 14:51, Paul Durrant wrote:
-Original Message-
From: Jürgen Groß
Sent: 03 December 2020 13:15
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Paul Durrant ; Andrew Cooper
; Anthony PERARD
; Christian Lindig ;
David Scott
; George Dunlap ; Ian Jackson
; Jan
Beulich ; J
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 solely because
of this duality.
This patch purges use of 'pcid
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 only properly enumerated
under '/local/domain/0/backend'.
This
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 patch also changes the type of the 'pci_domid' field in
'pci_ad
From: Paul Durrant
Simply spelling correction. Purely cosmetic fix.
Signed-off-by: Paul Durrant
Reviewed-by: Oleksandr Andrushchenko
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/
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 the
libxl_pci_assignable() test would have already failed.
Si
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 functions that support this writing to and reading from xenstore ar
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 observed
by running 'xl list -l' after adding a single device:
From: Paul Durrant
Paul Durrant (23):
xl / libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X
libxl: make libxl__device_list() work correctly for
LIBXL__DEVICE_KIND_PCI...
libxl: Make sure devices added by pci-attach are reflected in the
config
libxl: add/recover 'rdm_poli
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
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 +
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
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 -
1 file
From: Paul Durrant
This patch adds a 'name' field into the idl for 'libxl_device_pci' and
libxlu_pci_parse_spec_string() is modified to parse the new 'name'
parameter of PCI_SPEC_STRING detailed in the updated documention in
xl-pci-configuration(5).
If the 'name' field is non-NULL then both libx
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_device_pci_dispose() on each element of the returned list, but
libxl_
From: Paul Durrant
A subsequent patch will introduce code to allow a name to be specified to
'xl pci-assignable-add' such that the assignable device may be referred to
by than name in subsequent operations.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
docs/man/xl.1.pod.in
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 the device id de-assigned (or the
domain is destroyed). It is the
From: Paul Durrant
This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters
it via the newly introduced function. The new parser also deals with 'bdf'
and 'vslot' as non-positional paramaters, as per the documentation in
xl-pci-configuration(5).
The existing xlu_pci_parse_bdf(
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. The already-available COMPARE_PCI() macro can then be
used and it
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. Whilst all
current callers do ensure the memory is freed, only
From: Paul Durrant
... and prepare for adding support for non-positional parsing of 'bdf' and
'vslot' in a subsequent patch.
Also document 'BDF' as a first-class parameter type and fix the documentation
to state that the default value of 'rdm_policy' is actually 'strict', not
'relaxed', as can b
From: Paul Durrant
Currently the documentation completely fails to mention the existence of
PCI_SPEC_STRING. This patch tidies things up, specifically clarifying that
'pci-assignable-add/remove' take arguments where as 'pci-attach/detach'
take arguments (which will be enforced in a subsequent
p
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
will improve the documentation, once it is in its new location.
Si
From: Paul Durrant
... and use in 'libxl_device_pci'
This patch is preparatory work for restricting the type passed to functions
that only require BDF information, rather than passing a 'libxl_device_pci'
structure which is only partially filled. In this patch only the minimal
mechanical changes
From: Paul Durrant
Since assignable devices can be named, a subsequent patch will support use
of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In
this case the name will be used to look up the 'bdf' in the list of assignable
(or assigned) devices.
Signed-off-by: Paul Durran
From: Paul Durrant
This patch modifies libxl_device_pci_assignable_add() to take an optional
'name' argument, which (if supplied) is saved into xenstore and can hence be
used to refer to the now-assignable BDF in subsequent operations. To
facilitate this, a new libxl_device_pci_assignable_name2bd
From: Paul Durrant
... to use 'libxl_pci_bdf' rather than 'libxl_device_pci'.
This patch modifies the API and callers accordingly. It also modifies
several internal functions in libxl_pci.c that support the API to also use
'libxl_pci_bdf'.
NOTE: The OCaml bindings are adjusted to contain the in
On 30.11.2020 13:16, George Dunlap wrote:
>> On Nov 30, 2020, at 10:25 AM, Jan Beulich wrote:
>>
>> On 27.11.2020 12:52, George Dunlap wrote:
>>> The proposed agenda is in
>>> https://cryptpad.fr/pad/#/2/pad/edit/OPN55rXaOncupuWuHxtddzWJ/ and you can
>>> edit to add items. Alternatively, you ca
Hello Julien,
> On 2 Dec 2020, at 2:45 pm, Julien Grall wrote:
>
>
>
> On 26/11/2020 17:02, Rahul Singh wrote:
>> struct io_pgtable_ops, struct io_pgtable_cfg, struct iommu_flush_ops,
>> and struct iommu_ops related code are linux specific.
>
> So the assumption is we are going to support onl
Hello Stefano,
> On 3 Dec 2020, at 4:13 am, Stefano Stabellini wrote:
>
> On Wed, 2 Dec 2020, Julien Grall wrote:
>> On 02/12/2020 02:51, Stefano Stabellini wrote:
>>> On Thu, 26 Nov 2020, Rahul Singh wrote:
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
>>
On Thu, Dec 3, 2020 at 5:09 AM Jan Beulich wrote:
>
> On 02.12.2020 22:10, Julien Grall wrote:
> > On 23/11/2020 13:30, Jan Beulich wrote:
> >> While there don't look to be any problems with this right now, the lock
> >> order implications from holding the lock can be very difficult to follow
> >>
On 02.12.2020 16:46, Jürgen Groß wrote:
> On 01.12.20 09:21, Juergen Gross wrote:
>> @@ -1003,12 +1006,131 @@ static struct notifier_block cpu_nfb = {
>> .notifier_call = cpu_callback
>> };
>>
>> +#ifdef CONFIG_HYPFS
>> +static const struct hypfs_entry *cpupool_pooldir_enter(
>> +con
On 01.12.2020 09:21, Juergen Gross wrote:
> 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 writi
On 01.12.2020 09:21, Juergen Gross wrote:
> 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
> additi
On 03.12.20 15:46, Jan Beulich wrote:
On 02.12.2020 16:46, Jürgen Groß wrote:
On 01.12.20 09:21, Juergen Gross wrote:
@@ -1003,12 +1006,131 @@ static struct notifier_block cpu_nfb = {
.notifier_call = cpu_callback
};
+#ifdef CONFIG_HYPFS
+static const struct hypfs_entry *cpupool_
On 03.12.20 15:59, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
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
action
On 03.12.20 16:08, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
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 functio
On 03.12.2020 13:41, Paul Durrant wrote:
> From: Paul Durrant
>
> ...to control the visibility of the FIFO event channel operations
> (EVTCHNOP_init_control, EVTCHNOP_expand_array, and EVTCHNOP_set_priority) to
> the guest.
>
> These operations were added to the public header in commit d2d50c2f3
On 03.12.2020 16:14, Jürgen Groß wrote:
> On 03.12.20 15:59, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> @@ -100,11 +112,58 @@ static void hypfs_unlock(void)
>>> }
>>> }
>>>
>>> +const struct hypfs_entry *hypfs_node_enter(const struct hypfs_entry *entry)
>>> +{
>>
On 01.12.2020 09:21, Juergen Gross wrote:
> --- a/xen/common/hypfs.c
> +++ b/xen/common/hypfs.c
> @@ -355,6 +355,81 @@ unsigned int hypfs_getsize(const struct hypfs_entry
> *entry)
> return entry->size;
> }
>
> +int hypfs_read_dyndir_id_entry(const struct hypfs_entry_dir *template,
> +
> -Original Message-
> From: Jan Beulich
> Sent: 03 December 2020 15:23
> To: Paul Durrant
> Cc: Paul Durrant ; Eslam Elnikety ;
> Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Andrew Cooper
> ; George Dunlap ; Julien
> Grall ;
> Stefano Stabellini ; Christian Lindig
> ; David
> Scott
On 03.12.2020 16:45, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 03 December 2020 15:23
>>
>> On 03.12.2020 13:41, Paul Durrant wrote:
>>> From: Paul Durrant
>>>
>>> ...to control the visibility of the FIFO event channel operations
>>> (EVTCHNOP_init_control, EVTCHNOP_expand_array, and EVTC
flight 157166 xen-unstable real [real]
flight 157180 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157166/
http://logs.test-lab.xenproject.org/osstest/logs/157180/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Sat, Nov 14, 2020 at 2:01 AM Daniel Kiper wrote:
...
> The log specification should be as much as possible platform agnostic
> and self contained. The final version of this spec should be merged into
> existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone
> spec, e.g. as a
flight 157178 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157178/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 484e869dfd3b7e4b6c47cb65ae5d5f499fcc056e
baseline version:
ovmf 7c4ab1c2ef60a4690177d
> -Original Message-
> From: Jan Beulich
> Sent: 03 December 2020 15:57
> To: p...@xen.org
> Cc: 'Paul Durrant' ; 'Eslam Elnikety'
> ; 'Ian Jackson'
> ; 'Wei Liu' ; 'Anthony PERARD'
> ; 'Andrew
> Cooper' ; 'George Dunlap'
> ; 'Julien Grall'
> ; 'Stefano Stabellini' ; 'Christian
> Lindi
On 03.12.20 18:07, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 03 December 2020 15:57
To: p...@xen.org
Cc: 'Paul Durrant' ; 'Eslam Elnikety'
; 'Ian Jackson'
; 'Wei Liu' ; 'Anthony PERARD'
; 'Andrew
Cooper' ; 'George Dunlap'
; 'Julien Grall'
; 'Stefano Stabellini' ;
> -Original Message-
[snip]
>
> All of the hunks above point out a scalability issue if we were to
> follow this route for even just a fair part of new sub-ops, and I
> suppose you've noticed this with the next patch presumably touching
> all the same places again.
On Thu, 3 Dec 2020, Rahul Singh wrote:
> > On 3 Dec 2020, at 4:13 am, Stefano Stabellini
> > wrote:
> > On Wed, 2 Dec 2020, Julien Grall wrote:
> >> On 02/12/2020 02:51, Stefano Stabellini wrote:
> >>> On Thu, 26 Nov 2020, Rahul Singh wrote:
> +/* Alias to Xen device tree helpers */
> +
On Wed, 2 Dec 2020, Bertrand Marquis wrote:
> > On 28 Nov 2020, at 11:36, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > init_one_desc_irq() can return an error if it is unable to allocate
> > memory. While this is unlikely to happen during boot (called from
> > init_{,local_}irq_data()
flight 157174 qemu-mainline real [real]
flight 157185 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157174/
http://logs.test-lab.xenproject.org/osstest/logs/157185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 157176 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157176/
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-
flight 157184 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157184/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 126115a9fb3f89f8609336c87aa82fe7da19a9aa
baseline version:
ovmf 484e869dfd3b7e4b6c47c
flight 157182 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157182/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 157166
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 157191 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157191/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6af76adbbfccd31f4f8753fb0ddbbd9f4372f572
baseline version:
ovmf 126115a9fb3f89f860933
flight 157186 qemu-mainline real [real]
flight 157196 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157186/
http://logs.test-lab.xenproject.org/osstest/logs/157196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 157188 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157188/
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 03.12.2020 18:07, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 03 December 2020 15:57
>>
>> On 03.12.2020 16:45, Paul Durrant wrote:
From: Jan Beulich
Sent: 03 December 2020 15:23
On 03.12.2020 13:41, Paul Durrant wrote:
> From: Paul Durrant
>
> ...to cont
90 matches
Mail list logo
