On 05.08.2020 18:25, Andrew Cooper wrote:
> On 05/08/2020 15:54, Jan Beulich wrote:
>> On 05.08.2020 16:18, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -396,14 +396,14 @@ static void intel_log_freq(const struct cpuinfo_x86
>>> *c)
>>>
>>>
flight 152486 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 152331
Tests which did not s
flight 152484 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs.
On Wed, 5 Aug 2020, Julien Grall wrote:
> On 05/08/2020 00:22, Stefano Stabellini wrote:
> > On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > This patch adds ability to the device emulator to notify otherend
> > > (some entity running in the guest) usin
On Wed, 5 Aug 2020, Jan Beulich wrote:
> On 04.08.2020 21:11, Stefano Stabellini wrote:
> >> The point of the check isn't to determine whether to wait, but
> >> what to do after having waited. Reads need a retry round through
> >> the emulator (to store the result in the designated place),
> >> whi
On Wed, 5 Aug 2020, Julien Grall wrote:
> On 04/08/2020 20:11, Stefano Stabellini wrote:
> > On Tue, 4 Aug 2020, Julien Grall wrote:
> > > On 04/08/2020 12:10, Oleksandr wrote:
> > > > On 04.08.20 10:45, Paul Durrant wrote:
> > > > > > +static inline bool hvm_ioreq_needs_completion(const ioreq_t *i
On Thu, 6 Aug 2020, Oleksandr wrote:
> On 05.08.20 02:23, Stefano Stabellini wrote:
> > On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > This patch adds basic support for configuring and assisting virtio-disk
> > > backend (emualator) which is intended
On 05.08.20 19:15, Jan Beulich wrote:
Hi, Jan
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
--- a/xen/include/public/hvm/dm_op.h
+++ b/xen/include/public/hvm/dm_op.h
@@ -417,6 +417,20 @@ struct xen_dm_op_pin_memory_cacheattr {
uint32_t pad;
};
+/*
+ * XEN_DMOP_set_irq_level: S
On 05.08.20 02:23, Stefano Stabellini wrote:
Hi Stefano
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain
On 05.08.20 02:22, Stefano Stabellini wrote:
Hi Stefano
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to use device passthrough again.
Signed-off-by: Oleksandr Tyshchenko
---
tools/libxl/libxl_arm.c | 33 +++
On 05.08.20 02:23, Stefano Stabellini wrote:
Hi Stefano
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Without "dma-coherent" property present in virtio-mmio device node,
guest assumes it is non-coherent and making non-cacheable accesses
to the vring when the DM
flight 152494 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152494/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 05.08.20 19:13, Jan Beulich wrote:
Hi, Jan
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -713,14 +713,14 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct
domain *d, unsigned int
}
}
+#endif /* CONFIG_
flight 152480 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152480/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 151065
Tests which did not succee
On 05.08.20 19:41, Stefano Stabellini wrote:
Hi Stefano
On Wed, 5 Aug 2020, Jan Beulich wrote:
On 05.08.2020 01:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -385,10 +385,11 @@ static inline i
On 05.08.20 17:12, Julien Grall wrote:
Hi,
Hi Julien
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that support for
Arm64.
Also update XSM code a bit to let D
On 05/08/2020 19:19, Trammell Hudson wrote:
> When building xen from head with almost any combination of options, the
> resulting xen.efi seems properly formed. When CONFIG_LIVEPATCH is turned off,
> however, the resulting xen.efi is corrupted in some way and binutils no
> longer wants to work w
When building xen from head with almost any combination of options, the
resulting xen.efi seems properly formed. When CONFIG_LIVEPATCH is turned off,
however, the resulting xen.efi is corrupted in some way and binutils no longer
wants to work with it:
~/build/xen-clean/xen$ git rev-parse HEAD
8
This preliminary patch adds support for bundling the Xen hypervisor, xen.cfg,
the Linux kernel, initrd and XSM into a single "unified" EFI executable that
can be signed by sbsigntool for verification by UEFI Secure Boot. It is
inspired by systemd-boot's unified kernel technique and borrows the
On Wed, 5 Aug 2020, Jan Beulich wrote:
> On 05.08.2020 01:22, Stefano Stabellini wrote:
> > On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> >> --- a/xen/include/asm-arm/p2m.h
> >> +++ b/xen/include/asm-arm/p2m.h
> >> @@ -385,10 +385,11 @@ static inline int set_foreign_p2m_entry(struct
> >> domai
> -Original Message-
> From: Jan Beulich
> Sent: 05 August 2020 17:20
> To: Oleksandr Tyshchenko ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Andrew
> Cooper ; George Dunlap ;
> Ian Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; Daniel De Gr
On 05/08/2020 15:54, Jan Beulich wrote:
> On 05.08.2020 16:18, Andrew Cooper wrote:
>> A Gemini Lake platform prints:
>>
>> (XEN) CPU0: TSC: 1920MHz * 279 / 3 = 178560MHz
>> (XEN) CPU0: 800..1800 MHz
>>
>> during boot. The units on the first line are Hz, not MHz, so correct that
>> an
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> break;
> }
>
> +/* x86 already sets the flag in hvm_memory_op() */
> +#if
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Trying to run emulator in driver domain I ran into various issues
> mostly policy-related. So this patch tries to resolve all them
> plobably in a hackish way. I would like to get feedback how
> to implement them pr
> -Original Message-
> From: Jan Beulich
> Sent: 05 August 2020 17:06
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant
> Subject: Re: [PATCH v4 06/14] iommu: flush I/O TLB if iommu_map() or
> iommu_unmap() fail
>
> On 04.08.2020 15:42, Paul Durrant wrote:
> > From:
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 06881d0..f6fc3f8 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -70,6 +70,7 @@ extra-y := symbols-dummy.o
>
> obj-$(CONFIG_COVERAGE) += coverage/
> obj-y += sch
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -417,6 +417,20 @@ struct xen_dm_op_pin_memory_cacheattr {
> uint32_t pad;
> };
>
> +/*
> + * XEN_DMOP_set_irq_level: Set the logical level of a one of a domain
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -713,14 +713,14 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG
> struct domain *d, unsigned int
> }
> }
>
> +#endif /* CONFIG_X86 */
> +
> static XSM_INLINE int xsm_
On 04.08.2020 15:42, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch adds a full I/O TLB flush to the error paths of iommu_map() and
> iommu_unmap().
>
> Without this change callers need constructs such as:
>
> rc = iommu_map/unmap(...)
> err = iommu_flush(...)
> if ( !rc )
> rc = err
On 05.08.20 12:32, Julien Grall wrote:
Hi Julien.
Hi Stefano,
On 05/08/2020 00:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that su
On 04.08.2020 15:41, Paul Durrant wrote:
> From: Paul Durrant
>
> Instead of having separate page table allocation functions in VT-d and AMD
> IOMMU code, we could use a common allocation function in the general x86 code.
>
> This patch adds a new allocation function, iommu_alloc_pgtable(), for
On 05.08.2020 13:29, Trammell Hudson wrote:
> I have preliminary patches to support bundling the Xen hypervisor, xen.cfg,
> the Linux kernel, initrd and XSM into a single "unified" EFI executable that
> can be signed by sbsigntool for verification by UEFI Secure Boot. It is
> inspired by system
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ws16-amd64
testid windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbit
On 05.08.2020 15:54, Andrew Cooper wrote:
> The write into REGSEL prevents the optimiser from reusing the address
> calculation, forcing it to be calcualted twice.
>
> The calculation itself is quite expensive. Pull it out into a local varaible.
>
> Bloat-o-meter reports:
> add/remove: 0/0 gro
On 05.08.2020 14:51, Andrew Cooper wrote:
> This file is a mix of Xen and Linux styles. Switch it fully to Xen style.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
with a suggestion and, I'm afraid, a few more adjustments:
> --- a/xen/include/asm-x86/io_api
On 05.08.2020 14:51, Andrew Cooper wrote:
> In the case that bad_ioapic_register() fails, the current position of idx++
> means that clear_fixmap(idx) will be called with the wrong index, and not
> clean up the mapping just created.
>
> Increment idx as part of the loop, rather than midway through
On 05.08.2020 16:18, Andrew Cooper wrote:
> A Gemini Lake platform prints:
>
> (XEN) CPU0: TSC: 1920MHz * 279 / 3 = 178560MHz
> (XEN) CPU0: 800..1800 MHz
>
> during boot. The units on the first line are Hz, not MHz, so correct that and
> add a space for clarity.
>
> Also, for the mi
On 05.08.2020 16:12, Julien Grall wrote:
> On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-arm/hvm/ioreq.h
>> @@ -0,0 +1,103 @@
>> +/*
>> + * hvm.h: Hardware virtual machine assist interface definitions.
>> + *
>> + * Copyright (c) 2016 Citrix Systems Inc.
> -Original Message-
> From: Ian Jackson
> Sent: 05 August 2020 11:13
> To: Durrant, Paul
> Cc: p...@xen.org; xen-devel@lists.xenproject.org; 'Wei Liu'
> Subject: RE: [EXTERNAL] [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
> inform the frontend via
> xenstore
>
> CAUTION: This ema
Hi Oleksandr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.8 next-20200804]
[cannot apply to xen-tip/linux-next drm/drm-ne
A Gemini Lake platform prints:
(XEN) CPU0: TSC: 1920MHz * 279 / 3 = 178560MHz
(XEN) CPU0: 800..1800 MHz
during boot. The units on the first line are Hz, not MHz, so correct that and
add a space for clarity.
Also, for the min/max line, use three dots instead of two and add more space
Hi,
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that support for
Arm64.
Also update XSM code a bit to let DM op be used on Arm.
New arch DM op will be introduced in
The write into REGSEL prevents the optimiser from reusing the address
calculation, forcing it to be calcualted twice.
The calculation itself is quite expensive. Pull it out into a local varaible.
Bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 0/26 up/down: 0/-1527 (-1527)
Also correct th
> -Original Message-
> From: Ian Jackson
> Sent: 05 August 2020 10:31
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Wei Liu'
> Subject: RE: [EXTERNAL] [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
> inform the frontend via
> xenstore
>
> CAUTION: This
On 8/4/20 7:42 PM, Anchal Agarwal wrote:
>
> I think this could be done. PM_HIBERNATION_PREPARE could return -ENOTSUPP
> for arm and pvh dom0 when the notifier call chain is invoked for this case
> in hibernate(). This will then be an empty notifier just for checking two
> usecases.
> Also, for pvh
Hi,
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
splits IOREQ support into common and arch specific parts.
This support is going to be used on Arm to be able run device
emulator outside of Xen hyper
In the case that bad_ioapic_register() fails, the current position of idx++
means that clear_fixmap(idx) will be called with the wrong index, and not
clean up the mapping just created.
Increment idx as part of the loop, rather than midway through the loop body.
Signed-off-by: Andrew Cooper
---
C
This file is a mix of Xen and Linux styles. Switch it fully to Xen style.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/io_apic.h | 48 +--
1 file changed, 24 insertions(
flight 152482 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 152470 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
flight 152487 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152487/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
I have preliminary patches to support bundling the Xen hypervisor, xen.cfg, the
Linux kernel, initrd and XSM into a single "unified" EFI executable that can be
signed by sbsigntool for verification by UEFI Secure Boot. It is inspired by
systemd-boot's unified kernel technique and borrows the fu
flight 152488 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152488/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen c9f9a7258dc07735e2da2b6d0b51a0218c76a51f
baseline version:
xen 81fd
Durrant, Paul writes ("RE: [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
inform the frontend via xenstore"):
> > -Original Message-
> > From: Ian Jackson
...
> Well, I guess we address the driver domain issue in this way
> too... I will add a patch to libxl to write the libxl_device_n
Nick Rosbrook writes ("Re: [PATCH] libxl: avoid golang building without
CONFIG_GOLANG=y"):
> Jan - is the problem specifically that a fresh clone, or `git
> checkout`, etc. changes file timestamps in a way that triggers make to
> rebuild those targets? I have not used the move-if-changed approach
Hi,
On 05/08/2020 00:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed inte
Hi Stefano,
On 05/08/2020 00:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that support for
Arm64.
Also update XSM code a bit to let DM
Paul Durrant writes ("RE: [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
inform the frontend via xenstore"):
> > -Original Message-
> > From: Ian Jackson
...
> > Actually.
> >
> > This shouldn't be in the frontend at all, should it ? In general the
> > backend writes to the backend a
Hi,
On 04/08/2020 20:11, Stefano Stabellini wrote:
On Tue, 4 Aug 2020, Julien Grall wrote:
On 04/08/2020 12:10, Oleksandr wrote:
On 04.08.20 10:45, Paul Durrant wrote:
+static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
+{
+ return ioreq->state == STATE_IOREQ_READY &&
+
On 05.08.2020 01:22, Stefano Stabellini wrote:
> On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
>> --- a/xen/include/asm-arm/p2m.h
>> +++ b/xen/include/asm-arm/p2m.h
>> @@ -385,10 +385,11 @@ static inline int set_foreign_p2m_entry(struct domain
>> *d, unsigned long gfn,
>>
On 04.08.2020 21:11, Stefano Stabellini wrote:
>> The point of the check isn't to determine whether to wait, but
>> what to do after having waited. Reads need a retry round through
>> the emulator (to store the result in the designated place),
>> while writes don't have such a requirement (and henc
61 matches
Mail list logo
