flight 156711 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 156443
On 11/12/20 12:00 PM, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 02:50:30PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Update hardware domain's BAR header as R-Car Gen3 is a non-ECAM host
>> controller, so vPCI MMIO handlers do not work for it in hwdom.
>>
On 11/13/20 8:32 AM, Oleksandr Andrushchenko wrote:
>
> On 11/12/20 4:46 PM, Roger Pau Monné wrote:
>> On Thu, Nov 12, 2020 at 01:16:10PM +, Oleksandr Andrushchenko wrote:
>>> On 11/12/20 11:40 AM, Roger Pau Monné wrote:
On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko
On 11/12/20 11:56 AM, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 02:50:29PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Non-ECAM host bridges in hwdom go directly to PCI config space,
>> not through vpci (they use their specific method for accessing PCI
>>
On 11/12/20 4:46 PM, Roger Pau Monné wrote:
> On Thu, Nov 12, 2020 at 01:16:10PM +, Oleksandr Andrushchenko wrote:
>> On 11/12/20 11:40 AM, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git
On 12.11.20 22:38, Stefano Stabellini wrote:
On Thu, 12 Nov 2020, Jan Beulich wrote:
On 12.11.2020 13:50, Jürgen Groß wrote:
Any further comments, or even better, Acks?
To be honest I'd prefer to have at least one of the people Cc-ed
minimally indicate they consider this a good idea. No need
Hi Christoph,
> The update_bdev argument is always set to true, so remove it. Also
> rename the function to the slighly less verbose set_capacity_and_notify,
> as propagating the disk size to the block device isn't really
> revalidation.
> Signed-off-by: Christoph Hellwig
Reviewed-by: Petr
flight 156705 qemu-mainline real [real]
flight 156732 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156705/
http://logs.test-lab.xenproject.org/osstest/logs/156732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
HI Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2020年11月9日 20:04
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Andre Przywara ; Bertrand Marquis
> ; Wei Chen ; Kaly Xin
> ; nd
> Subject: Re: [PATCH] xen/arm: Add Cortex-A73 erratum 858921
flight 156687 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156687/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail like 156397
flight 156702 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156702/
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
The function will be moved to common QOM code, as it is not
specific to TYPE_DEVICE anymore.
Reviewed-by: Stefan Berger
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Rename to object_field_prop_ptr() instead of object_static_prop_ptr()
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc:
Every single qdev property setter function manually checks
dev->realized. We can just check dev->realized inside
qdev_property_set() instead.
The check is being added as a separate function
(qdev_prop_allow_set()) because it will become a callback later.
Reviewed-by: Stefan Berger
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
- Fix build error with CONFIG_XEN
I took the liberty of keeping the Reviewed-by line from
Marc-André as the build fix is a trivial one line change
On Thu, 12 Nov 2020, Jan Beulich wrote:
> On 12.11.2020 13:50, Jürgen Groß wrote:
> > Any further comments, or even better, Acks?
>
> To be honest I'd prefer to have at least one of the people Cc-ed
> minimally indicate they consider this a good idea. No need for a
> close review or such, just a
flight 156685 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156685/
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
Okay so before having the meeting webex/whatever link, I think it would be
more efficient to plan a kind of agenda, something we can pass to the
OpenPOWER team in the next few days. This way, they could have some answers
ready, allowing us to explore more things interactively during the meeting.
On Thu, Nov 12, 2020 at 06:27:04PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 12, 2020 at 05:32:40PM +0100, Roger Pau Monné wrote:
> > On Thu, Nov 12, 2020 at 04:57:15PM +0100, Manuel Bouyer wrote:
> > Can you give a try to the following debug patch and paste what you
> > get?
> >
> > Thanks,
flight 156693 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156693/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 8ab15139728a8efd3ebbb60beb16a958a6a93fa1
baseline version:
xtf
On 12/11/2020 17:27, Manuel Bouyer wrote:
> On Thu, Nov 12, 2020 at 05:32:40PM +0100, Roger Pau Monné wrote:
>> On Thu, Nov 12, 2020 at 04:57:15PM +0100, Manuel Bouyer wrote:
>>> Hello,
>>> I'm trying to add dom0 PVH support to NetBSD. I'm tesing with Xen 4.13
>>> on a brand new Intel x86 server
At 15:04 +0100 on 12 Nov (1605193496), Jan Beulich wrote:
> On 12.11.2020 14:07, Roger Pau Monné wrote:
> > On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote:
> >> I agree with all this. If only it was merely about TLB flushes. In
> >> the shadow case, shadow_blow_all_tables() gets
On Thu, Nov 12, 2020 at 05:32:40PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 12, 2020 at 04:57:15PM +0100, Manuel Bouyer wrote:
> > Hello,
> > I'm trying to add dom0 PVH support to NetBSD. I'm tesing with Xen 4.13
> > on a brand new Intel x86 server (Dell R440).
>
> I would recommend using
On 12.11.2020 17:32, Roger Pau Monné wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -371,7 +371,12 @@ static int msix_write(struct vcpu *v, unsigned long
> addr, unsigned int len,
> entry->updated = false;
> }
> else
> +{
> +
flight 156677 linux-5.4 real [real]
flight 156721 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156677/
http://logs.test-lab.xenproject.org/osstest/logs/156721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On Thu, Nov 12, 2020 at 04:57:15PM +0100, Manuel Bouyer wrote:
> Hello,
> I'm trying to add dom0 PVH support to NetBSD. I'm tesing with Xen 4.13
> on a brand new Intel x86 server (Dell R440).
I would recommend using 4.14, PVH dom0 is still very much in
progress, and while I don't recall any
flight 156684 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156684/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c48866e041d2afaabb170086c5bb0c69a4653d3
baseline version:
ovmf
Hello,
I'm trying to add dom0 PVH support to NetBSD. I'm tesing with Xen 4.13
on a brand new Intel x86 server (Dell R440).
While the dom0 kernel configures hardware, Xen panics with:
(XEN) Xen call trace:
(XEN)[] R vpci_msix_arch_mask_entry+0x18/0x20
(XEN)[] S
On 12.11.20 14:41, Jan Beulich wrote:
On 12.11.2020 14:14, Juergen Gross wrote:
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -89,6 +89,7 @@ static unsigned int cpu_mask_to_apicid_x2apic_cluster(const
cpumask_t *cpumask)
static void
On Thu, Nov 12, 2020 at 01:16:10PM +, Oleksandr Andrushchenko wrote:
>
> On 11/12/20 11:40 AM, Roger Pau Monné wrote:
> > On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >> diff --git a/xen/drivers/vpci/header.c
On 12.11.2020 14:07, Roger Pau Monné wrote:
> On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote:
>> On 11.11.2020 13:17, Roger Pau Monné wrote:
>>> On Tue, Nov 10, 2020 at 03:50:44PM +0100, Jan Beulich wrote:
On 10.11.2020 14:59, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at
On 12.11.2020 14:14, Juergen Gross wrote:
> Instead of calling send_guest_vcpu_virq() from NMI context use the
> NMI continuation framework for that purpose. This avoids taking locks
> in NMI mode.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 12.11.2020 14:14, Juergen Gross wrote:
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -89,6 +89,7 @@ static unsigned int cpu_mask_to_apicid_x2apic_cluster(const
> cpumask_t *cpumask)
>
> static void send_IPI_self_x2apic(uint8_t vector)
> {
> +/* NMI
On 12.11.2020 13:50, Jürgen Groß wrote:
> Any further comments, or even better, Acks?
To be honest I'd prefer to have at least one of the people Cc-ed
minimally indicate they consider this a good idea. No need for a
close review or such, just a basic opinion. Anyone?
Jan
On 11/12/20 11:40 AM, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> At the moment there is an identity mapping between how a guest sees its
>> BARs and how they are programmed into guest domain's p2m. This
Move sending of a virq event for oprofile to the local vcpu from NMI
to normal interrupt context.
This has been tested with a small test patch using the continuation
framework of patch 1 for all NMIs and doing a print to console in
the continuation handler.
Version 1 of this small series was
Instead of calling send_guest_vcpu_virq() from NMI context use the
NMI continuation framework for that purpose. This avoids taking locks
in NMI mode.
Signed-off-by: Juergen Gross
---
V5:
- use Linux coding style (Jan Beulich)
- assume races could happen (Jan Beulich)
V4:
- rework to less
Actions in NMI context are rather limited as e.g. locking is rather
fragile.
Add a framework to continue processing in normal interrupt context
after leaving NMI processing.
This is done by a high priority interrupt vector triggered via a
self IPI from NMI context, which will then call the
Instead of using a softirq pci_serr_error() can use NMI continuation
for issuing an error message.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V5:
- make PCISERR higher prior than oprofile (Jan Beulich)
V4:
- rework to less generic approach
---
xen/arch/x86/traps.c | 21
On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote:
> On 11.11.2020 13:17, Roger Pau Monné wrote:
> > On Tue, Nov 10, 2020 at 03:50:44PM +0100, Jan Beulich wrote:
> >> On 10.11.2020 14:59, Roger Pau Monné wrote:
> >>> On Wed, Oct 28, 2020 at 10:24:53AM +0100, Jan Beulich wrote:
> ---
On 12.11.20 12:36, Jan Beulich wrote:
On 12.11.2020 12:27, Jürgen Groß wrote:
On 12.11.20 12:05, Jan Beulich wrote:
On 12.11.2020 11:48, Jürgen Groß wrote:
On 12.11.20 11:23, Jan Beulich wrote:
On 11.11.2020 16:48, Jürgen Groß wrote:
On 11.11.20 16:45, Jan Beulich wrote:
On 09.11.2020
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> This is the second version of providing a base to support device MSI (non
> PCI based) and on top of that support for IMS (Interrupt Message Storm)
> based devices in a halfways architecture independent way.
Hi Thomas,
Our test
On 11/11/20 4:44 PM, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 02:50:25PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Host bridge controller's ECAM space is mapped into Domain-0's p2m,
>> thus it is not possible to trap the same for vPCI via MMIO handlers.
On 11/11/20 4:54 PM, Jan Beulich wrote:
> On 09.11.2020 13:50, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -879,6 +879,43 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
>> return ret;
>> }
>>
>> +#ifdef
On 29.10.20 15:49, Jan Beulich wrote:
On 29.10.2020 15:40, Jürgen Groß wrote:
On 29.10.20 15:22, Jan Beulich wrote:
On 22.10.2020 16:39, Juergen Gross wrote:
@@ -507,6 +509,41 @@ void __init initialize_keytable(void)
}
}
+#define CRASHACTION_SIZE 32
+static char
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On 11.11.2020 13:17, Roger Pau Monné wrote:
> On Tue, Nov 10, 2020 at 03:50:44PM +0100, Jan Beulich wrote:
>> On 10.11.2020 14:59, Roger Pau Monné wrote:
>>> On Wed, Oct 28, 2020 at 10:24:53AM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1380,6 +1380,27 @@ int guest_physmap_remove_page(struct domain *d, gfn_t
> gfn, mfn_t mfn,
> return p2m_remove_mapping(d, gfn, (1 << page_order), mfn);
> }
>
> +int
flight 156670 xen-4.14-testing real [real]
flight 156715 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156670/
http://logs.test-lab.xenproject.org/osstest/logs/156715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 11:45
> To: Oleksandr Tyshchenko ; Paul Durrant
> Cc: Oleksandr Tyshchenko ; Andrew Cooper
> ;
> Roger Pau Monné ; Wei Liu ; George Dunlap
> ; Ian Jackson ; Julien Grall
> ; Stefano
> Stabellini ; Jun Nakajima ;
> Kevin
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> --- a/xen/include/asm-x86/hvm/io.h
> +++ b/xen/include/asm-x86/hvm/io.h
> @@ -97,7 +97,6 @@ bool relocate_portio_handler(
> unsigned int size);
>
> void send_timeoffset_req(unsigned long timeoff);
> -void send_invalidate_req(void);
> bool
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> --- a/xen/common/ioreq.c
> +++ b/xen/common/ioreq.c
> @@ -18,6 +18,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
There preferably wouldn't be a need to touch non-Arm code in this
patch. I suppose the added
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch removes "hvm" prefixes and infixes from IOREQ
> related function names in the common code.
AT least some of the functions touched here would be nice to be
moved to a more consistent new naming scheme
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -30,6 +30,10 @@
> #include
> #include
>
> +#ifdef CONFIG_IOREQ_SERVER
> +#include
> +#endif
Preferably #ifdef-s would not be needed here. If any, they'd better
live in xen/ioreq.h
On 12.11.2020 12:27, Jürgen Groß wrote:
> On 12.11.20 12:05, Jan Beulich wrote:
>> On 12.11.2020 11:48, Jürgen Groß wrote:
>>> On 12.11.20 11:23, Jan Beulich wrote:
On 11.11.2020 16:48, Jürgen Groß wrote:
> On 11.11.20 16:45, Jan Beulich wrote:
>> On 09.11.2020 10:50, Juergen Gross
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> As a lot of x86 code can be re-used on Arm later on, this patch
> splits devicemodel support into common and arch specific parts.
>
> The common DM feature is supposed to be built with IOREQ_SERVER
> option enabled (as
On 12.11.20 12:05, Jan Beulich wrote:
On 12.11.2020 11:48, Jürgen Groß wrote:
On 12.11.20 11:23, Jan Beulich wrote:
On 11.11.2020 16:48, Jürgen Groß wrote:
On 11.11.20 16:45, Jan Beulich wrote:
On 09.11.2020 10:50, Juergen Gross wrote:
static int nmi_callback(const struct cpu_user_regs
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> --- a/xen/include/asm-x86/hvm/ioreq.h
> +++ b/xen/include/asm-x86/hvm/ioreq.h
> @@ -77,7 +77,7 @@ static inline int hvm_map_mem_type_to_ioreq_server(struct
> domain *d,
> if ( flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE )
> return
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> As a lot of x86 code can be re-used on Arm later on, this patch
> moves previously prepared x86/hvm/ioreq.c to the common code.
>
> The common IOREQ feature is supposed to be built with IOREQ_SERVER
> option
On 12.11.2020 11:48, Jürgen Groß wrote:
> On 12.11.20 11:23, Jan Beulich wrote:
>> On 11.11.2020 16:48, Jürgen Groß wrote:
>>> On 11.11.20 16:45, Jan Beulich wrote:
On 09.11.2020 10:50, Juergen Gross wrote:
>static int nmi_callback(const struct cpu_user_regs *regs, int cpu)
>{
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
> 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 for
> a code movement in
Hey Jan,
>>
>> Note that Linux's arm32 atomics helpers use the READ_ONCE() and
>> WRITE_ONCE() macros defined in , while Linux's
>> arm64 atomics helpers use __READ_ONCE() and __WRITE_ONCE().
>
> And our ACCESS_ONCE() can't be used, or be made usable? I don't think
> we want a 3rd variant when
On 12.11.20 10:29, Jan Beulich wrote:
On 09.11.2020 10:50, Juergen Gross wrote:
Instead of using a softirq pci_serr_error() can use NMI continuation
for issuing an error message.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with one minor change to be considered:
@@ -1808,6
On 12.11.20 11:23, Jan Beulich wrote:
On 11.11.2020 16:48, Jürgen Groß wrote:
On 11.11.20 16:45, Jan Beulich wrote:
On 09.11.2020 10:50, Juergen Gross wrote:
@@ -83,14 +85,28 @@ void passive_domain_destroy(struct vcpu *v)
model->free_msr(v);
}
+bool
On Fri, Oct 23, 2020 at 10:38:04AM +0200, Jan Beulich wrote:
> Under certain conditions CPUs can speculate into the instruction stream
> past a RET instruction. Guard against this just like 3b7dab93f240
> ("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
> did - by inserting an
On 11.11.2020 16:48, Jürgen Groß wrote:
> On 11.11.20 16:45, Jan Beulich wrote:
>> On 09.11.2020 10:50, Juergen Gross wrote:
>>> @@ -83,14 +85,28 @@ void passive_domain_destroy(struct vcpu *v)
>>> model->free_msr(v);
>>> }
>>>
>>> +bool nmi_oprofile_send_virq(void)
>>> +{
>>> +
On Mon, Nov 09, 2020 at 02:50:30PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Update hardware domain's BAR header as R-Car Gen3 is a non-ECAM host
> controller, so vPCI MMIO handlers do not work for it in hwdom.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
>
On Mon, Nov 09, 2020 at 02:50:29PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Non-ECAM host bridges in hwdom go directly to PCI config space,
> not through vpci (they use their specific method for accessing PCI
> configuration, e.g. dedicated registers etc.). Thus
On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> At the moment there is an identity mapping between how a guest sees its
> BARs and how they are programmed into guest domain's p2m. This is not
> going to work as guest domains have their
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 08:38
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH 02/10] viridian: move IPI hypercall
> implementation into
On 09.11.2020 10:50, Juergen Gross wrote:
> Instead of using a softirq pci_serr_error() can use NMI continuation
> for issuing an error message.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with one minor change to be considered:
> @@ -1808,6 +1816,9 @@ bool
On 11.11.2020 21:07, Paul Durrant wrote:
> --- a/xen/include/asm-x86/hvm/viridian.h
> +++ b/xen/include/asm-x86/hvm/viridian.h
> @@ -59,6 +59,14 @@ struct viridian_domain
> {
> union hv_guest_os_id guest_os_id;
> union hv_vp_assist_page_msr hypercall_gpa;
> +unsigned long
On 11.11.2020 21:07, Paul Durrant wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -553,6 +553,83 @@ static unsigned int vpmask_next(struct hypercall_vpmask
> *vpmask, unsigned int vp
>(vp) < HVM_MAX_VCPUS; \
>(vp) =
flight 156663 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
On 11.11.2020 21:07, Paul Durrant wrote:
> 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
>
On 11.11.2020 21:07, Paul Durrant wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -533,6 +533,21 @@ static bool vpmask_test(struct hypercall_vpmask *vpmask,
> unsigned int vp)
> return test_bit(vp, vpmask->mask);
> }
>
> +static
On 11.11.2020 21:07, Paul Durrant wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -507,15 +507,41 @@ void viridian_domain_deinit(struct domain *d)
> XFREE(d->arch.hvm.viridian);
> }
>
> +struct hypercall_vpmask {
> +
On 11.11.2020 21:07, Paul Durrant wrote:
> 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
On 11.11.2020 22:51, Ash Wilding wrote:
> From: Ash Wilding
>
> This patch pulls in Linux's atomics helpers for arm32 and arm64, and
> their dependencies, as-is.
>
> Note that Linux's arm32 atomics helpers use the READ_ONCE() and
> WRITE_ONCE() macros defined in , while Linux's
> arm64 atomics
Thanks to everyone who participated in the poll. Due to the limited number
of answers, I think it's wiser to go for the second option (Thursday the
19th), because everyone who already answered seems available that day. I'll
confirm that to OpenPOWER. When it's confirmed, I'll do a recap here
On 11.11.2020 21:01, Andrew Cooper wrote:
> On 11/11/2020 15:11, Jan Beulich wrote:
>> On 11.11.2020 13:45, Andrew Cooper wrote:
>>> Clang 9 and later don't handle the clobber of %r10 correctly in
>>> _hypercall64_4(). See https://bugs.llvm.org/show_bug.cgi?id=48122
>> Are you sure this is a bug?
80 matches
Mail list logo
