Hi Michal,
> -Original Message-
> Subject: [PATCH 2/3] xen/arm: vpl011: Handle correctly TXFE when backend in
> Xen
>
> When backend is in Xen, the handling of data written to DR register is a
> bit special because we want to tell guest that we are always ready for new
> data to be writte
flight 180208 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180208/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180199
test-amd64-amd64-xl-qemuu-win7-amd64
On 32 bit systems with 64 bit time_t (hello, Y2038 problem),
the following error occurs otherwise:
| xenstored_control.c: In function 'lu_reject_reason':
| xenstored_control.c:646:70: error: format '%ld' expects argument of type
'long int', but argument 5 has type 'time_t' {aka 'long long int'}
On Tue, Apr 11, 2023 at 11:41:04PM +, Volodymyr Babchuk wrote:
>
> Hi Roger,
>
> Roger Pau Monné writes:
>
> > On Tue, Mar 14, 2023 at 08:56:29PM +, Volodymyr Babchuk wrote:
> >> Prior to this change, lifetime of pci_dev objects was protected by global
> >> pcidevs_lock(). Long-term pla
flight 180216 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180216/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b991aec0509f24ae7573d732ba337549ecee310c
baseline version:
ovmf 51734dfc48466eddfb0f8
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
---
CHanges from v4:
- no changes
Changes from v3:
- no changes
Changes from v2:
- no changes
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/a
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- No changes
Changes from v3:
- No changes
Changes from v2:
- No changes
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/arch
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot only when SVE resources are accessed.
While there, correct coding style for the comment on coprocessor
trapping.
Now cptr_el2 is part of the domain context
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how many bits
are supported by the platform.
Save P0
Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
to allow the domain to have an information about the SVE feature
and the number of SVE register bits that are allowed for this
domain.
sve_vl field is the vector length in bits divided by 128, this
allows to use less space in the st
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and
when availab
Add a command line parameter to allow Dom0 the use of SVE resources,
the command line parameter sve=, sub argument of dom0=,
controls the feature on this domain and sets the maximum SVE vector
length for Dom0.
Add a new function, parse_signed_integer(), to parse an integer
command line argument.
On Arm, the SVE vector length is encoded in arch_capabilities field
of struct xen_sysctl_physinfo, make use of this field in the tools
when building for arm.
Create header arm-arch-capabilities.h to handle the arch_capabilities
field of physinfo for Arm.
Removed include for xen-tools/common-macro
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- Now it is possible to specify the property "sve" for dom0less
device tree node without any value, that means the platform
When the arm platform supports SVE, advertise the feature in the
field arch_capabilities in struct xen_sysctl_physinfo by encoding
the SVE vector length in it.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- Write arch_capabilities from arch_do_physinfo instead of using
stub functions (Ja
Currently x86 defines a Xen command line argument dom0= where
there can be specified dom0 controlling sub-options, to use it also
on Arm, move the code that loops through the list of arguments from
x86 to the common code and from there, call architecture specific
functions to handle the comma separ
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- Rename sve field to sve_vl (Anthony), changed type to
libxl_sve_type
- Sanity check of sve field in libxl instead of xl, update docs
(Anthony)
- drop Ack-by from
Arm now can use the "dom0=" Xen command line option and the support
for guests running SVE instructions is added, put entries in the
changelog.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- No changes
Change from v3:
- new patch
---
CHANGELOG.md | 5 +
1 file changed, 5 insertions(+)
Hi Luca,
> -Original Message-
> Subject: [PATCH v5 12/12] xen/changelog: Add SVE and "dom0" options to the
> changelog for Arm
>
> Arm now can use the "dom0=" Xen command line option and the support
> for guests running SVE instructions is added, put entries in the
> changelog.
>
> Signe
On 12/4/23 07:39, Thomas Huth wrote:
On 11/04/2023 23.04, Vikram Garhwal wrote:
Xen is supported for aarch64 via xenpvh machine. disable-tcg option
fails the
build for aarch64 target.
Link for xen on arm patch series:
https://mail.gnu.org/archive/html/qemu-devel/2023-02/msg03979.html
Signed
Vikram Garhwal writes:
> Xen is supported for aarch64 via xenpvh machine. disable-tcg option fails the
> build for aarch64 target.
>
> Link for xen on arm patch series:
> https://mail.gnu.org/archive/html/qemu-devel/2023-02/msg03979.html
>
> Signed-off-by: Vikram Garhwal
> ---
> .gitlab-ci.d
On Tue, Apr 11, 2023 at 10:27:45PM +, Volodymyr Babchuk wrote:
>
> Hello Roger,
>
> Sorry for the late answer.
>
> Roger Pau Monné writes:
>
> > On Tue, Mar 14, 2023 at 08:56:29PM +, Volodymyr Babchuk wrote:
> >> We can use reference counter to ease up object lifetime management.
> >>
On Tue, Apr 11, 2023 at 12:20:13PM +0100, Andrew Cooper wrote:
> On 11/04/2023 11:30 am, Simon Gaiser wrote:
> > Hi,
> >
> > I have been recently looking into getting S0ix working on Xen [1].
> >
> > Thanks to a tip from Andrew I found that the HPET legacy mode was
> > preventing my test system fro
flight 180209 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180209/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 180084
test-amd64-i386-xl-qemut-win7-am
Alex Bennée writes:
> Vikram Garhwal writes:
>
>> Xen is supported for aarch64 via xenpvh machine. disable-tcg option fails the
>> build for aarch64 target.
>>
>> Link for xen on arm patch series:
>> https://mail.gnu.org/archive/html/qemu-devel/2023-02/msg03979.html
>>
>> Signed-off-by: Vikram
Vikram Garhwal writes:
> Add CONFIG_XEN for aarch64 device to support build for ARM targets.
>
> Signed-off-by: Vikram Garhwal
> Signed-off-by: Stefano Stabellini
> Reviewed-by: Alex Bennée
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.buil
Fabiano Rosas writes:
> Vikram Garhwal writes:
>
>> Add CONFIG_XEN for aarch64 device to support build for ARM targets.
>>
>> Signed-off-by: Vikram Garhwal
>> Signed-off-by: Stefano Stabellini
>> Reviewed-by: Alex Bennée
>> ---
>> meson.build | 2 +-
>> 1 file changed, 1 insertion(+), 1 de
flight 180217 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180217/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 179840
test-amd64-amd64-xl-qemut-ws16-a
Hi all,
Yes, gdbstub build issue is only for for aarch64-softmmu target and that
was the reason for this patch. x86 targets build fine with
''disable-tcg" option.
Thanks Fabiano & Philippe for sharing the existing patch series for this.
Regards,
Vikram
On 4/12/23 5:51 AM, Fabiano Rosas w
Hi all,
this is what I have in "xenstored-access.log" in dom0 :
[20230411T23:48:27.917Z] D5 write control/feature-balloon 1
[20230411T23:48:27.917Z] D5 error EACCES
[20230411T23:48:27.923Z] D5 write data/updated Wed Apr 12
01:48:27 CEST 2023
It happens o
On 12.04.23 17:48, zithro wrote:
Hi all,
this is what I have in "xenstored-access.log" in dom0 :
[20230411T23:48:27.917Z] D5 write control/feature-balloon 1
[20230411T23:48:27.917Z] D5 error EACCES
[20230411T23:48:27.923Z] D5 write data/updated Wed Apr 12
On 12/04/2023 4:48 pm, zithro wrote:
> Hi all,
>
> this is what I have in "xenstored-access.log" in dom0 :
>
> [20230411T23:48:27.917Z] D5 write control/feature-balloon 1
> [20230411T23:48:27.917Z] D5 error EACCES
> [20230411T23:48:27.923Z] D5 write data/updat
Hi all,
On 4/12/23 18:05, Andrew Cooper wrote:
> On 12/04/2023 4:48 pm, zithro wrote:
>> Hi all,
>>
>> this is what I have in "xenstored-access.log" in dom0 :
>>
>> [20230411T23:48:27.917Z] D5 write control/feature-balloon 1
>> [20230411T23:48:27.917Z] D5 error EACCES
>>
Hello,
I've done various backports to staging-4.14 and later trying to improve
the state of Gitlab testing.
The good news is that 4.16 and 4.17 now pass. The bad news is that
there are still bugs which need fixing, but lets start with the older
branches.
Also, I was forced to backport an update
flight 180211 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180211/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-i386 7 xen-installfail in 180206 pass in 180211
test-amd64-i386-xl-qemuu-dmrestr
On Tue, 2023-04-11 at 19:07 +0100, Peter Maydell wrote:
>
>
> > +static void xs_be_unwatch(struct qemu_xs_handle *h, struct
> > qemu_xs_watch *w)
> > +{
> > + xs_impl_unwatch(h->impl, DOMID_QEMU, w->path, NULL,
> > xs_be_watch_cb, w);
>
> Coverity points out that this is the only call to xs_i
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Michal Orzel
Successful run:
https://cirrus-ci.com/task/6232358978846720
---
.cirrus.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.cirrus.yml b/.cirrus.yml
index b133afb74057..9bb6cce4
The Long Mode consistency checks exist to "ensure that the processor does not
enter an undefined mode or state that results in unpredictable behavior". APM
Vol2 Table 14-5 "Long-Mode Consistency Checks" lists them, but there is no row
preventing the OS from trying to exit Long mode while in 64bit
From: David Woodhouse
Coverity points out that if (!s && !s->impl) isn't really what we intended
to do here. CID 1508131.
Fixes: 032475127225 ("hw/xen: Add emulated implementation of XenStore
operations")
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 2 +-
1 file changed, 1
From: David Woodhouse
Coverity spotted a double-free (CID 1508254); we g_string_free(path) and
then for some reason immediately call free(path) too.
We should just use g_autoptr() for it anyway, which simplifies the code
a bit.
Fixes: 7a8a749da7d3 ("hw/xen: Move xenstore_store_pv_console_info t
From: David Woodhouse
I initially put the basic platform init (overlay pages, grant tables,
event channels) into mc->kvm_type because that was the earliest place
that could sensibly test for xen_mode==XEN_EMULATE.
The intent was to do this early enough that we could then initialise the
XenBus an
Some Coverity fixes and minor cleanups. And most notably, dropping
support for Xen libraries older than 4.7.1.
I believe there are two issues that remain to be fixed. The x32 build
fails, and I've seen patches which attempt to detect x32 and disable
the Xen emulation. Along with assertions that we
From: David Woodhouse
In restructuring to allow for internal emulation of Xen functionality,
I broke compatibility for Xen 4.6 and earlier. Fix this by explicitly
removing support for anything older than 4.7.1, which is also ancient
but it does still build, and the compatibility support for it is
From: David Woodhouse
There was a superfluous allocation of the XS handle, leading to it
being leaked on both the error path and the success path (where it gets
allocated again).
Spotted by Coverity (CID 1508098).
Fixes: ba2a92db1ff6 ("hw/xen: Add xenstore operations to allow redirection to
in
On Wed, 12 Apr 2023 at 19:22, David Woodhouse wrote:
>
> On Tue, 2023-04-11 at 19:07 +0100, Peter Maydell wrote:
> >
> >
> > > +static void xs_be_unwatch(struct qemu_xs_handle *h, struct
> > > qemu_xs_watch *w)
> > > +{
> > > +xs_impl_unwatch(h->impl, DOMID_QEMU, w->path, NULL,
> > > xs_be_wat
On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
>
> Some Coverity fixes and minor cleanups. And most notably, dropping
> support for Xen libraries older than 4.7.1.
>
> I believe there are two issues that remain to be fixed. The x32 build
> fails, and I've seen patches which attempt to detect
On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
>
> From: David Woodhouse
>
> Coverity points out that if (!s && !s->impl) isn't really what we intended
> to do here. CID 1508131.
>
> Fixes: 032475127225 ("hw/xen: Add emulated implementation of XenStore
> operations")
> Signed-off-by: David
On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
>
> From: David Woodhouse
>
> Coverity spotted a double-free (CID 1508254); we g_string_free(path) and
> then for some reason immediately call free(path) too.
>
> We should just use g_autoptr() for it anyway, which simplifies the code
> a bit.
On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
> >
> > Some Coverity fixes and minor cleanups. And most notably, dropping
> > support for Xen libraries older than 4.7.1.
> >
> > I believe there are two issues that remain to be fixed
On Wed, 2023-04-12 at 20:01 +0100, David Woodhouse wrote:
> On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> > On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
> > >
> > > Some Coverity fixes and minor cleanups. And most notably, dropping
> > > support for Xen libraries older than 4.
flight 180221 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180221/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 89520115b89d755ae79f61850c356aae4be2d9ad
baseline version:
ovmf b991aec0509f24ae7573d
Hi Andrew,
On 12/04/2023 17:05, Andrew Cooper wrote:
On 12/04/2023 4:48 pm, zithro wrote:
Hi all,
this is what I have in "xenstored-access.log" in dom0 :
[20230411T23:48:27.917Z] D5 write control/feature-balloon 1
[20230411T23:48:27.917Z] D5 error EACCES
[20230411T23
On Wed, 11 Apr 2023, David Woodhouse wrote:
> Some Coverity fixes and minor cleanups. And most notably, dropping
> support for Xen libraries older than 4.7.1.
I just wanted to say that I am fine with this
On Wed, 12 Apr 2023, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Michal Orzel
>
> Successful run:
> https://cirrus-ci.com/task/6232358978846720
> ---
> .cirrus.yml | 2 +-
> 1 file changed, 1
flight 180213 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180213/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15 migrate-s
flight 180223 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180223/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5430f7f60dee3747fff906b48718db8afb4589d9
baseline version:
ovmf 89520115b89d755ae79f6
Hi Roger,
First of all, I want to provide link [1] to the RFC series where I tried
total PCI locking rework. After discussing with Jan, it became clear for
me, that task is much harder, than I anticipated. So, it was decided to
move with a smaller steps. First step is to make vPCI code independed
On Wed, 12 Apr 2023, Andrew Cooper wrote:
> Hello,
>
> I've done various backports to staging-4.14 and later trying to improve
> the state of Gitlab testing.
>
> The good news is that 4.16 and 4.17 now pass. The bad news is that
> there are still bugs which need fixing, but lets start with the o
flight 180218 xen-4.15-testing real [real]
flight 180224 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180218/
http://logs.test-lab.xenproject.org/osstest/logs/180224/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 180226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180226/
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
flight 180219 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180219/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180086
test-amd64-amd64-xl-qemuu-win7-a
61 matches
Mail list logo
