On 01.12.2020 19:53, Oleksandr wrote:
> On 01.12.20 13:03, Alex Bennée wrote:
>> Oleksandr Tyshchenko writes:
>>> @@ -1112,19 +1155,11 @@ int hvm_map_mem_type_to_ioreq_server(struct domain
>>> *d, ioservid_t id,
>>> if ( s->emulator != current->domain )
>>> goto out;
>>>
>>> -
On 01.12.2020 18:40, Roger Pau Monne wrote:
> 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
Since the line num
On 01.12.2020 09:21, Juergen Gross wrote:
> 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
Reviewed-by: Jan Beulich
with one small q
On 30.11.2020 18:39, 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
From: Paul Durrant
If hvm_guest_x86_mode() returns something other than 8 or 4 then
viridian_hypercall() will return immediately but, on the way out, will write
back status as if 'mode' was 4. This patch simply makes it leave the registers
alone.
NOTE: The formatting of the 'out' label and the s
From: Paul Durrant
Paul Durrant (11):
viridian: don't blindly write to 32-bit registers is 'mode' is invalid
viridian: move flush hypercall implementation into separate function
viridian: move IPI hypercall implementation into separate function
viridian: introduce a per-cpu hypercall_vpma
From: Paul Durrant
... and make use of them in hvcall_flush()/need_flush().
Subsequent patches will need to deal with virtual processor masks potentially
wider than 64 bits. Thus, to avoid using too much stack, this patch
introduces global per-cpu virtual processor masks and converts the
impleme
From: Paul Durrant
A subsequent patch will need to IPI a mask of virtual processors potentially
wider than 64 bits. A previous patch introduced per-cpu hypercall_vpmask
to allow hvcall_flush() to deal with such wide masks. This patch modifies
the implementation of hvcall_ipi() to make use of the
From: Paul Durrant
This patch moves the implementation of HVCALL_SEND_IPI that is currently
inline in viridian_hypercall() into a new hvcall_ipi() function.
The new function returns Xen errno values similarly to hvcall_flush(). Hence
the errno translation code in viridial_hypercall() is generali
From: Paul Durrant
This patch moves the implementation of HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST
that is currently inline in viridian_hypercall() into a new hvcall_flush()
function.
The new function returns Xen erro values which are then dealt with
appropriately. A return value of -ERESTART tra
From: Paul Durrant
vlapic_ipi() uses a softirq batching mechanism to improve the efficiency of
sending a IPIs to large number of processors. This patch modifies send_ipi()
(the worker function called by hvcall_ipi()) to also make use of the
mechanism when there multiple bits set the hypercall_vpm
From: Paul Durrant
A previous patch introduced variants of the flush hypercalls that take a
'Virtual Processor Set' as an argument rather than a simple 64-bit mask.
This patch introduces a similar variant of the HVCALL_SEND_IPI hypercall
(HVCALL_SEND_IPI_EX).
NOTE: As with HVCALL_FLUSH_VIRTUAL_A
From: Paul Durrant
To make is simpler to observe which viridian hypercalls are issued by a
particular Windows guest, this patch adds a per-domain mask to track them.
Each type of hypercall causes a different bit to be set in the mask and
when the bit transitions from clear to set, a log line is e
From: Paul Durrant
The Microsoft Hypervisor TLFS specifies variants of the already implemented
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST hypercalls that take a 'Virtual
Processor Set' as an argument rather than a simple 64-bit mask.
This patch adds a new hvcall_flush_ex() function to implement the
On 01.12.2020 00:59, Igor Druzhinin wrote:
> Current limit of 7 is too restrictive for modern systems where one GSI
> could be shared by potentially many PCI INTx sources where each of them
> corresponds to a device passed through to its own guest. Some systems do not
> apply due dilligence in swiz
On 02.12.2020 10:21, Paul Durrant wrote:
> From: Paul Durrant
>
> If hvm_guest_x86_mode() returns something other than 8 or 4 then
> viridian_hypercall() will return immediately but, on the way out, will write
> back status as if 'mode' was 4. This patch simply makes it leave the registers
> alon
> -Original Message-
> From: Jan Beulich
> Sent: 02 December 2020 09:29
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 01/11] viridian: don't blindly write to 32-bit
> registers is 'mode' is
flight 157155 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157155/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 3ae469af8e680df31eecd0a2ac6a83b58ad7ce53
baseline version:
xen f7d7
On 02.12.20 09:58, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
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
Reviewed-by:
On 30.11.2020 17:50, Hongyan Xia wrote:
> 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
On 27.11.20 17:07, t...@redhat.com wrote:
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
On 02.12.2020 10:56, Jürgen Groß wrote:
> On 02.12.20 09:58, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> 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_al
On 02.12.20 11:46, Jan Beulich wrote:
On 02.12.2020 10:56, Jürgen Groß wrote:
On 02.12.20 09:58, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
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 pro
On 02.12.2020 08:48, Juergen Gross wrote:
> 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
>
HI Volodymyr,
> On 1 Dec 2020, at 16:54, Volodymyr Babchuk wrote:
>
>
> 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, V
flight 157137 xen-4.11-testing real [real]
flight 157156 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157137/
http://logs.test-lab.xenproject.org/osstest/logs/157156/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 02.12.20 10:00, Jan Beulich wrote:
Hi Jan
On 01.12.2020 19:53, Oleksandr wrote:
On 01.12.20 13:03, Alex Bennée wrote:
Oleksandr Tyshchenko writes:
@@ -1112,19 +1155,11 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d,
ioservid_t id,
if ( s->emulator != current->domain )
Hi,
> On 2 Dec 2020, at 11:12, Bertrand Marquis wrote:
>
> HI Volodymyr,
>
>> On 1 Dec 2020, at 16:54, Volodymyr Babchuk
>> wrote:
>>
>>
>> Hi,
>>
>> Bertrand Marquis writes:
>>
>>> Hi Volodymyr,
>>>
On 1 Dec 2020, at 12:07, Volodymyr Babchuk
wrote:
Hi,
On Wed, 2020-12-02 at 11:04 +0100, Jan Beulich wrote:
> On 30.11.2020 17:50, Hongyan Xia wrote:
> > 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 g
flight 157157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:
> @@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe,
> SYM_L_GLOBAL)
>* Try to use SYSRET instead of IRET if we're returning to
>* a completely clean 64-bit userspace context. If we're not,
>
On 02.12.2020 13:17, Hongyan Xia wrote:
> On Wed, 2020-12-02 at 11:04 +0100, Jan Beulich wrote:
>> On 30.11.2020 17:50, Hongyan Xia wrote:
>>> +l3page = virt_to_page(pl3e);
>>> +L3T_LOCK(l3page);
>>> +
>>> +ASSERT(l3e_get_flags(*pl3e) & _PAGE_PRESENT);
>>> +if ( l3e_get_flags(*pl3e)
Hello Stefano,
Thanks for reviewing the code.
> On 1 Dec 2020, at 10:23 pm, Stefano Stabellini wrote:
>
> 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
>> comm
Hello Stefano,
> On 2 Dec 2020, at 12:39 am, Stefano Stabellini wrote:
>
> 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-
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 wrote:
>>> XEN does not support MSI on ARM platforms, therefore remove the MSI
>>> support from SMMUv3 driver.
>>>
>>> Signed-off-by: Rahu
Hello Stefano,
> On 2 Dec 2020, at 12:53 am, Stefano Stabellini wrote:
>
> 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 test
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
commands-queue insertion is not implemented in XEN therefore revert the
patch that implemented the commands-qu
flight 157138 xen-4.10-testing real [real]
flight 157159 xen-4.10-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157138/
http://logs.test-lab.xenproject.org/osstest/logs/157159/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
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 but not
the consequences. I think this is quite important to have them outline
Hi Rahul,
On 26/11/2020 17:02, Rahul Singh wrote:
PCI ATS functionality is not implemented and tested on ARM.
I agree that short term, this is not going to be implemented. However, I
do expect this feature to be used medium term (mostly likely before the
driver is out of tech preview).
So
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 wrote:
XEN does not support MSI on ARM platforms, therefore remove the MSI
support from SMMU
Hello Stefano,
> On 2 Dec 2020, at 1:48 am, Stefano Stabellini wrote:
>
> 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 i
flight 157150 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157150/
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
Hi Rahul,
On 02/12/2020 14:34, Rahul Singh wrote:
dev_info(smmu->dev, "ias %lu-bit, oas %lu-bit (features 0x%08x)\n",
@@ -2595,9 +2208,6 @@ static int arm_smmu_device_dt_probe(struct
platform_device *pdev,
parse_driver_options(smmu);
- if (of_dma_is_coherent(dev->of_node
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 only sharing with the P2M
and the IOMMU. That's probably fine short term, but long
On 02.12.20 13:32, Borislav Petkov wrote:
On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:
@@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe,
SYM_L_GLOBAL)
* Try to use SYSRET instead of IRET if we're returning to
* a completely clean 64-bit us
While reviewing Hongyan's "x86/vmap: handle superpages in
vmap_to_mfn()" it became apparent that the interaction of
xen/mm.h and asm/page.h is problematic. Therefore some basic
page size related definitions get moved out of the latter, and
the mfn_t et al ones out of the former, each into new heade
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 replacement / removal to
some x86 headers as well; some others now need to include page.h (and
they reall
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
dependencies.
Replace xen/mm.h inclusion where possible in include/xen/. (In
xen/iommu.h also
On 02/12/2020 09:25, Jan Beulich wrote:
> On 01.12.2020 00:59, Igor Druzhinin wrote:
>> Current limit of 7 is too restrictive for modern systems where one GSI
>> could be shared by potentially many PCI INTx sources where each of them
>> corresponds to a device passed through to its own guest. Some
On 02.12.2020 15:53, Igor Druzhinin wrote:
> On 02/12/2020 09:25, Jan Beulich wrote:
>> On 01.12.2020 00:59, Igor Druzhinin wrote:
>>> Current limit of 7 is too restrictive for modern systems where one GSI
>>> could be shared by potentially many PCI INTx sources where each of them
>>> corresponds t
On 01.12.2020 09:21, Juergen Gross wrote:
> @@ -297,6 +321,7 @@ int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
> int ret;
>
> ASSERT(this_cpu(hypfs_locked) == hypfs_write_locked);
> +ASSERT(leaf->e.max_size);
>
> if ( ulen > leaf->e.max_size )
> return -ENOSPC;
On 02.12.20 16:36, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -297,6 +321,7 @@ int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
int ret;
ASSERT(this_cpu(hypfs_locked) == hypfs_write_locked);
+ASSERT(leaf->e.max_size);
if ( ulen > leaf->e.max_s
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 contents are being generated.
>
> For directories add a findentry callback to the vector an
On 01.12.20 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)
- call hypfs_add_dir() in helper (Dario Faggioli)
- switch loc
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 contents are being generated.
For directories add a find
Hi Rahul,
On 26/11/2020 17:02, 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 suppor
Hello Stefano,
> On 2 Dec 2020, at 2:51 am, Stefano Stabellini wrote:
>
> 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 S
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 don't look to be
>>> any restrictions on the pre
Julien Grall writes ("Re: Xen 4.15: Proposed release schedule"):
> Therefore, would it be possible to push the "Feature Freeze" by week?
Sure. To expand on that: this was the only comment on my proposal,
and I'm happy to accept such a minor change.
Adjusting the LPD too, but not the other two te
Currently the arguments for xenwatchdogd are hardcoded with 15s
keep-alive interval and 30s timeout.
It is not possible to tweak these values via
/etc/systemd/system/xen-watchdog.service.d/*.conf because ExecStart
can not be replaced. The only option would be a private copy
/etc/systemd/system/xen
Hi Stefano,
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
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#
> 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()), it is better to harden the code by
> propagting the r
On Wed, Dec 02, 2020 at 03:48:21PM +0100, Jürgen Groß wrote:
> I wanted to avoid the additional NOPs for the bare metal case.
Yeah, in that case it gets optimized to a single NOP:
[0.176692] SMP alternatives: 81a00068: [0:5) optimized NOPs: 0f 1f
44 00 00
which is nopl 0x0(%rax,%rax
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 replacement / removal to
s/repsecitve/respective/
Hi Jan,
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
dependencies.
Replace xen/mm.h inclusion w
Hi,
On 30/11/2020 02:50, Tian, Kevin wrote:
From: Julien Grall
Sent: Thursday, November 19, 2020 10:52 PM
From: Julien Grall
When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will
throw
the following splat:
(XEN)
===
On 26/11/2020 11:27, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2020年11月26日 18:55
To: Wei Chen ; Stefano Stabellini
Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
Andre Przywara ; Bertrand Marquis
; Kaly Xin ; nd
Subject: Re: [PATCH] xen/ar
flight 157142 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
Hi Jan,
On 05/11/2020 15:55, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway.
Given there are not many users of grant-table v2, would it make sense to
avoid allocating the array until the guest start u
Hi Jan,
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 per-vCPU virq_lock is going to be sufficien
flight 157143 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 157131
test-amd64-i386-qemut-rhel6hvm-
Hi Stefano,
> On 2 Dec 2020, at 4:27 pm, Rahul Singh wrote:
>
> Hello Stefano,
>
>> On 2 Dec 2020, at 2:51 am, Stefano Stabellini wrote:
>>
>> On Thu, 26 Nov 2020, Rahul Singh wrote:
>>> Add support for ARM architected SMMUv3 implementation. It is based on
>>> the Linux SMMUv3 driver.
>>>
>>
On Wed, Dec 2, 2020 at 11:47 AM Olaf Hering wrote:
>
> Currently the arguments for xenwatchdogd are hardcoded with 15s
> keep-alive interval and 30s timeout.
>
> It is not possible to tweak these values via
> /etc/systemd/system/xen-watchdog.service.d/*.conf because ExecStart
> can not be replaced
Hi Jan,
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 callbacks don't
(and no such callback should) hav
Hi Jan,
On 23/11/2020 13:28, Jan Beulich wrote:
Use {read,write}_atomic() to exclude any eventualities, in particular
observing that accesses aren't all happening under a consistent lock.
Requested-by: Julien Grall
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
---
v3: New
flight 157147 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157147/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
in 157123 pass in 157147
test-a
flight 157163 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157163/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
... and increase default "irq_max_guests" to 32.
It's not necessary to have an array of a size more than 1 for non-shareable
IRQs and it might impact scalability in case of high "irq_max_guests"
values being used - every IRQ in the system including MSIs would be
supplied with an array of that size
... and increase the default to 16.
Current limit of 7 is too restrictive for modern systems where one GSI
could be shared by potentially many PCI INTx sources where each of them
corresponds to a device passed through to its own guest. Some systems do not
apply due dilligence in swizzling INTx lin
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2020年12月3日 2:11
> To: Wei Chen ; Stefano Stabellini
> Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
> Andre Przywara ; Bertrand Marquis
> ; Kaly Xin ; nd
>
> Subject: Re: [PATCH] xen/arm: Add Cortex-A73 erratum 858921 work
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
> > > +#define of_phandle_args dt_phandle_args
> > > +#define of_device_id dt_
On Thu, 3 Dec 2020, Wei Chen wrote:
> Hi Julien,
>
> > -Original Message-
> > From: Julien Grall
> > Sent: 2020年12月3日 2:11
> > To: Wei Chen ; Stefano Stabellini
> > Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
> > Andre Przywara ; Bertrand Marquis
> > ; Kaly Xin ; nd
> >
> > Subjec
flight 157153 linux-5.4 real [real]
flight 157170 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157153/
http://logs.test-lab.xenproject.org/osstest/logs/157170/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
Standardizing in-memory logging sounds like an interesting idea,
especially with regards to components that can run on top of different
firmware stacks (things like GRUB or TF-A). But I would be a bit wary
of creating a "new standard to rule them all" and then expecting all
projects to switch what
Currently the arguments for xenwatchdogd are hardcoded with 15s
keep-alive interval and 30s timeout.
It is not possible to tweak these values via
/etc/systemd/system/xen-watchdog.service.d/*.conf because ExecStart
can not be replaced. The only option would be a private copy
/etc/systemd/system/xen
On 03.12.20 07:34, Olaf Hering wrote:
Currently the arguments for xenwatchdogd are hardcoded with 15s
keep-alive interval and 30s timeout.
It is not possible to tweak these values via
/etc/systemd/system/xen-watchdog.service.d/*.conf because ExecStart
can not be replaced. The only option would b
Am Thu, 3 Dec 2020 07:47:58 +0100
schrieb Jürgen Groß :
> Could you please add a section for XENWATCHDOGD_ARGS in
> tools/hotplug/Linux/init.d/sysconfig.xencommons.in ?
No. Such details have to go into a to-be-written xencommons(8).
There will be a xenwatchdogd(8) shortly, which will cover this
flight 157162 qemu-mainline real [real]
flight 157173 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157162/
http://logs.test-lab.xenproject.org/osstest/logs/157173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
89 matches
Mail list logo
