flight 161417 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161417/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f2f4c6be2dba3f8e97ac544b9c3da71e9f81b294
baseline version:
ovmf 61680cac5e435053be89a
flight 161407 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161404 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161404/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161393
test-armhf-armhf-libvirt 16 save
On Fri, Apr 23, 2021 at 12:19 PM Sergey Kovalev wrote:
>
>
> 23.04.2021 18:08, Roger Pau Monné пишет:
> > On Fri, Apr 23, 2021 at 01:22:34PM +0300, Sergey Kovalev wrote:
> >> # Abstract
> >>
> >> After `xl save win win.mem` and then `xl restore win.hvm win.mem`
> >> the Windows 10 VM remain frozen
flight 161401 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161401/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
flight 161406 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161406/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 61680cac5e435053be89a4fc6b945466f2c7bac6
baseline version:
ovmf d3b0d007a135284981fa7
flight 161413 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161413/
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 161397 xen-4.12-testing real [real]
flight 161412 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161397/
http://logs.test-lab.xenproject.org/osstest/logs/161412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 161409 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161409/
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
The sysconfig variable XENSTORED_ROOTDIR is not used anymore.
It used to point to a directory with tdb files, which is now a tmpfs.
Fixes commit 2ef6ace428dec4795b8b0a67fff6949e817013de
Signed-off-by: Olaf Hering
---
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 7 ---
tools/hotplug/
A hard to trigger race with another unrelated systemd service and
xenstored.service unveiled a bug in the way how xenstored is launched
with systemd.
launch-xenstore may start either a daemon or a domain. In case a domain
is used, systemd-notify was called. If another service triggered a
restart o
23.04.2021 18:08, Roger Pau Monné пишет:
On Fri, Apr 23, 2021 at 01:22:34PM +0300, Sergey Kovalev wrote:
# Abstract
After `xl save win win.mem` and then `xl restore win.hvm win.mem`
the Windows 10 VM remain frozen for about a minute. After the
minute it becomes responsive.
During the freeze
`device` parameter is deprecated since QEMU 2.8.
This requires changes to the command line introduced by:
"libxl: Use -device for cd-rom drives"
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_disk.c | 43 +--
1 file changed, 36 insertions(+), 7 dele
We are going to want to check QEMU's version in other places where we
can use libxl__ev_qmp_send.
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_internal.h | 8
tools/libs/light/libxl_qmp.c | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/li
This allows to set an `id` on the device instead of only the drive. We
are going to need the `id` with the "eject" and
"blockdev-change-media" QMP command as using `device` parameter on
those is deprecated. (`device` is the `id` of the `-drive` on the
command line).
We set the same `id` on both -d
We are supposed to read the version information only when qmp_ev is in
state "Connected" (that correspond to state==qmp_state_connected),
assert it so that the function isn't used too early.
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_qmp.c | 2 ++
1 file changed, 2 insertions(+)
d
The command "cpu-add" for CPU hotplug is deprecated and has been
removed from QEMU 6.0 (April 2021). We need to add cpus with the
command "device_add" now.
In order to find out which parameters to pass to "device_add" we first
make a call to "query-hotpluggable-cpus" which list the cpus drivers
an
Short-form boolean options are deprecated in QEMU 6.0.
Upstream commit that deprecate those: ccd3b3b8112b ("qemu-option: warn
for short-form boolean options").
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_dm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
"change" command as been removed in QEMU 6.0. We can use
"blockdev-change-medium" instead.
Using `id` with "blockdev-change-medium" requires a change to the QEMU
command line, introduced by:
"libxl: Use -device for cd-rom drives"
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_disk
We use the deprecated QMP command "query-cpus" which is removed in the
QEMU 6.0 release. There's a replacement which is "query-cpus-fast",
and have been available since QEMU 2.12 (April 2018).
This patch try the new command first and when the command isn't
available, it fall back to the deprecated
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.deprecated-qemu-qmp-and-cmd-v1
The Xen 4.15 release that went out just before QEMU 6.0 won't be compaptible
with the latter. This patch series fixes libxl to replace use of QMP commands
On Fri, Apr 23, 2021 at 01:22:34PM +0300, Sergey Kovalev wrote:
> # Abstract
>
> After `xl save win win.mem` and then `xl restore win.hvm win.mem`
> the Windows 10 VM remain frozen for about a minute. After the
> minute it becomes responsive.
>
> During the freeze the OS remains semi-responsive:
On 23.04.21 12:19, Olaf Hering wrote:
The string is for the binary within the domain, not for the domain itself.
Sorry, that is not true.
Just because the Mini-OS based xenstore stubdom doesn't need any other
parameters but the xenstore ones doesn't mean that this is true for all
possible xens
On 23.04.2021 16:25, Roger Pau Monné wrote:
> On Fri, Apr 23, 2021 at 01:03:34PM +0200, Jan Beulich wrote:
>> PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at
>> least 2.36 would silently truncate the (negative) difference when a
>> section is placed below the image base. Such
On 23.04.2021 16:17, Roger Pau Monné wrote:
> On Fri, Apr 23, 2021 at 12:52:57PM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/shadow/set.c
>> +++ b/xen/arch/x86/mm/shadow/set.c
>> @@ -94,6 +94,15 @@ shadow_get_page_from_l1e(shadow_l1e_t sl
>> ASSERT(!sh_l1e_is_magic(sl1e));
>> ASSER
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
While there drop the checks for the accessibility of one struct
frame_head beyond the current one: it's not clear why it's needed and
all the hypnoses point to dropp
On Fri, Apr 23, 2021 at 01:04:10PM +0200, Jan Beulich wrote:
> ... provided the linker supports it (which it does as of commit
> 2dfa8341e079 ["ELF DWARF in PE output"]).
>
> Without mentioning debugging sections, the linker would put them at
> VA 0, thus making them unreachable by 32-bit (relativ
On Fri, Apr 23, 2021 at 01:03:34PM +0200, Jan Beulich wrote:
> PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at
> least 2.36 would silently truncate the (negative) difference when a
> section is placed below the image base. Such sections would also be
> wrongly placed ahead of
On Fri, Apr 23, 2021 at 12:52:57PM +0200, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/shadow/set.c
> +++ b/xen/arch/x86/mm/shadow/set.c
> @@ -94,6 +94,15 @@ shadow_get_page_from_l1e(shadow_l1e_t sl
> ASSERT(!sh_l1e_is_magic(sl1e));
> ASSERT(shadow_mode_refcounts(d));
>
> +/*
> +
Hi,
We are trying to find Raspberry like mobile HW that can run Xen with
full features enabled like pass through devices and iommu support.
So far we have tried these:
These don't have iommu:
* Raspberry Pi 4b
iommu doesn't cover whole io address space only some devices are behind
iommu:
On 23.04.2021 15:51, Roger Pau Monné wrote:
> On Fri, Apr 23, 2021 at 02:53:14PM +0200, Jan Beulich wrote:
>> On 23.04.2021 14:35, Roger Pau Monne wrote:
>>> Remove the unneeded usage of the compat layer to copy frame pointers
>>> from guest address space. Instead just use raw_copy_from_guest.
>>>
On Fri, Apr 23, 2021 at 02:53:14PM +0200, Jan Beulich wrote:
> On 23.04.2021 14:35, Roger Pau Monne wrote:
> > Remove the unneeded usage of the compat layer to copy frame pointers
> > from guest address space. Instead just use raw_copy_from_guest.
> >
> > Reported-by: Andrew Cooper
> > Signed-off
On 23/04/2021 12:08, Jan Beulich wrote:
> On 23.04.2021 13:04, Andrew Cooper wrote:
>> On 23/04/2021 11:58, Jan Beulich wrote:
>>> On 23.04.2021 12:51, Andrew Cooper wrote:
On 23/04/2021 10:50, Roger Pau Monné wrote:
> On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
>> On
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption,
On 23/04/2021 13:53, Jan Beulich wrote:
> On 23.04.2021 14:35, Roger Pau Monne wrote:
>> Remove the unneeded usage of the compat layer to copy frame pointers
>> from guest address space. Instead just use raw_copy_from_guest.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Roger Pau Monné
>> --
On 23.04.2021 15:30, Георгий Зайцев wrote:
> Thanks, but now I'll need to understand what your quoted "frozen" and
>> "unfrozen" mean. Plus obviously comparators and main counter are also
>> different, and it's there where I suspect the issue is
>
> "frozen" - this is initial snapshot which takes
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2
Thanks, but now I'll need to understand what your quoted "frozen" and
> "unfrozen" mean. Plus obviously comparators and main counter are also
> different, and it's there where I suspect the issue is
"frozen" - this is initial snapshot which takes about from 30 seconds to 1
minute after restore to
On 23.04.2021 15:17, Roger Pau Monne wrote:
> When restoring limit the maximum leaves to the ones supported by Xen
> 4.12 in order to not expand the maximum leaves a guests sees. Note
> this is unlikely to cause real issues.
>
> Guests restored from Xen versions 4.13 or greater will contain CPUID
On 23.04.2021 15:10, Георгий Зайцев wrote:
>>
>> Since
>> you've taken apart saved state, could you supply the full set of
>> values (ideally multiple ones, if you happen to have them, plus
>> ones where the problem didn't occur, to allow someone perhaps
>> spot a pattern)?
>>
>
> Here is full HPE
When restoring limit the maximum leaves to the ones supported by Xen
4.12 in order to not expand the maximum leaves a guests sees. Note
this is unlikely to cause real issues.
Guests restored from Xen versions 4.13 or greater will contain CPUID
data on the stream that will override the values set b
>
> Since
> you've taken apart saved state, could you supply the full set of
> values (ideally multiple ones, if you happen to have them, plus
> ones where the problem didn't occur, to allow someone perhaps
> spot a pattern)?
>
Here is full HPET state from "frozen" snapshot according to hvm_hw_hpe
23.04.2021 15:30, Jan Beulich пишет:
> "Patched successfully" meaning the guest, when resumed using that
> state, did not stall initially?
Yes.
> In any event, if HPET_TN_PERIODIC was set after unfreeze, it was
> also set upon saving state. (Or are you suggesting the flag got
> "magically" set?
On 23.04.2021 14:51, Andrew Cooper wrote:
> On 23/04/2021 13:35, Roger Pau Monne wrote:
>> Remove the unneeded usage of the compat layer to copy frame pointers
>> from guest address space. Instead just use raw_copy_from_guest.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Roger Pau Monné
>>
On 23.04.2021 14:35, Roger Pau Monne wrote:
> Remove the unneeded usage of the compat layer to copy frame pointers
> from guest address space. Instead just use raw_copy_from_guest.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> Just build tested. Note sure I'm missing so
On 23/04/2021 13:35, Roger Pau Monne wrote:
> Remove the unneeded usage of the compat layer to copy frame pointers
> from guest address space. Instead just use raw_copy_from_guest.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> Just build tested. Note sure I'm missing som
flight 161395 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs.
152332
test-amd64-i3
On Fri, Apr 23, 2021 at 02:41:32PM +0200, Jan Beulich wrote:
> On 23.04.2021 12:54, Roger Pau Monne wrote:
> > When restoring limit the maximum leaves to the ones supported by Xen
> > 4.13 in order to not expand the maximum leaf a guests sees. Note this
> > is unlikely to cause real issues.
>
> Wh
On 23.04.2021 12:54, Roger Pau Monne wrote:
> When restoring limit the maximum leaves to the ones supported by Xen
> 4.13 in order to not expand the maximum leaf a guests sees. Note this
> is unlikely to cause real issues.
Why 4.13 (and not 4.12) here when ...
> Guests restored from Xen versions
Remove the unneeded usage of the compat layer to copy frame pointers
from guest address space. Instead just use raw_copy_from_guest.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Just build tested. Note sure I'm missing something, since using the
compat layer here was IMO much mo
On 23.04.2021 12:22, Sergey Kovalev wrote:
> # Abstract
>
> After `xl save win win.mem` and then `xl restore win.hvm win.mem`
> the Windows 10 VM remain frozen for about a minute. After the
> minute it becomes responsive.
>
> During the freeze the OS remains semi-responsive: on `Ctrl+Shift+Esc`
>
On 22/04/2021 09:14, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 80 ++
On 23.04.2021 13:04, Andrew Cooper wrote:
> On 23/04/2021 11:58, Jan Beulich wrote:
>> On 23.04.2021 12:51, Andrew Cooper wrote:
>>> On 23/04/2021 10:50, Roger Pau Monné wrote:
On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
> On 16.04.2021 15:41, Andrew Cooper wrote:
>> O
On 23/04/2021 11:58, Jan Beulich wrote:
> On 23.04.2021 12:51, Andrew Cooper wrote:
>> On 23/04/2021 10:50, Roger Pau Monné wrote:
>>> On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
On 16.04.2021 15:41, Andrew Cooper wrote:
> On 16/04/2021 09:16, Jan Beulich wrote:
>> cla
While without debug info the difference is benign (so far), since we pad
the image to 16Mb anyway, forcing the .reloc section to a 2Mb boundary
causes subsequent .debug_* sections to go farther beyond 16Mb than
needed. There's no reason to advance . for establishing __2M_rwdata_end,
as all data pas
... provided the linker supports it (which it does as of commit
2dfa8341e079 ["ELF DWARF in PE output"]).
Without mentioning debugging sections, the linker would put them at
VA 0, thus making them unreachable by 32-bit (relative or absolute)
relocations. If relocations were resolvable (or absent)
PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at
least 2.36 would silently truncate the (negative) difference when a
section is placed below the image base. Such sections would also be
wrongly placed ahead of all "normal" ones. Since, for the time being,
we build xen.efi with
Since it was requested and is possible with up-to-date binutils, inclusion
of debug info in xen.efi is the remaining part here. The other changes here
are cleanup related to both the work here as well as the one to make
binutils fit for our purposes.
1: EFI: sections may not live at VA 0 in PE bin
On 23.04.2021 12:51, Jan Beulich wrote:
> 1: VMX: use a single, global APIC access page
> 2: x86/shadow: re-use variables in shadow_get_page_from_l1e()
> 3: x86/shadow: streamline shadow_get_page_from_l1e()
I'm sorry, I'm noticing only now that I've typoed the version.
Jan
On 23.04.2021 12:51, Andrew Cooper wrote:
> On 23/04/2021 10:50, Roger Pau Monné wrote:
>> On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
>>> On 16.04.2021 15:41, Andrew Cooper wrote:
On 16/04/2021 09:16, Jan Beulich wrote:
> clang, at the very least, doesn't like unused inli
On Fri, Apr 23, 2021 at 12:45:14PM +0200, Jan Beulich wrote:
> On 23.04.2021 12:07, Roger Pau Monné wrote:
> > On Fri, Apr 23, 2021 at 10:51:40AM +0200, Jan Beulich wrote:
> >> On 23.04.2021 09:30, Roger Pau Monné wrote:
> >>> /*
> >>> * Explicitly list debug section for the PE output so that they
When restoring limit the maximum leaves to the ones supported by Xen
4.13 in order to not expand the maximum leaf a guests sees. Note this
is unlikely to cause real issues.
Guests restored from Xen versions 4.13 or greater will contain CPUID
data on the stream that will override the values set by
Trying get_page_from_l1e() up to three times isn't helpful; in debug
builds it may lead to log messages making things look as if there was a
problem somewhere. And there's no need to have more than one try: The
function can only possibly succeed for one domain passed as 3rd
argument (unless the pag
There's little point in doing multiple mfn_to_page() or page_get_owner()
on all the same MFN. Calculate them once at the start of the function.
Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
---
v5: Integrate into series. Re-base.
v2: Re-base.
--- a/xen/arch/x86/mm/shadow/set.c
+++ b/xen/arch/
The address of this page is used by the CPU only to recognize when to
access the virtual APIC page instead. No accesses would ever go to this
page. It only needs to be present in the (CPU) page tables so that
address translation will produce its address as result for respective
accesses.
By making
1: VMX: use a single, global APIC access page
2: x86/shadow: re-use variables in shadow_get_page_from_l1e()
3: x86/shadow: streamline shadow_get_page_from_l1e()
Jan
On 23/04/2021 10:50, Roger Pau Monné wrote:
> On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
>> On 16.04.2021 15:41, Andrew Cooper wrote:
>>> On 16/04/2021 09:16, Jan Beulich wrote:
clang, at the very least, doesn't like unused inline functions, unless
their definitions live
On 23.04.2021 12:07, Roger Pau Monné wrote:
> On Fri, Apr 23, 2021 at 10:51:40AM +0200, Jan Beulich wrote:
>> On 23.04.2021 09:30, Roger Pau Monné wrote:
>>> /*
>>> * Explicitly list debug section for the PE output so that they don't
>>> * end up at VA 0 which is below image base and thus invalid
flight 161393 xen-unstable real [real]
flight 161403 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161393/
http://logs.test-lab.xenproject.org/osstest/logs/161403/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-
Ping?
On Fri, May 17, Olaf Hering wrote:
> A hard to trigger race with another unrelated systemd service and
> xenstored.service unveiled a bug in the way how xenstored is launched
> with systemd.
>
> launch-xenstore may start either a daemon or a domain. In case a domain
> is used, systemd-noti
# Abstract
After `xl save win win.mem` and then `xl restore win.hvm win.mem`
the Windows 10 VM remain frozen for about a minute. After the
minute it becomes responsive.
During the freeze the OS remains semi-responsive: on `Ctrl+Shift+Esc`
press the wait cursor appears (blue circle indicator).
T
The string is for the binary within the domain, not for the domain itself.
Fixes commit 83c365e6395f39c7ff91785b400682173d5e5d04
Signed-off-by: Olaf Hering
---
tools/helpers/init-xenstore-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/helpers/init-xenstore-do
On Fri, Apr 23, 2021 at 10:51:40AM +0200, Jan Beulich wrote:
> On 23.04.2021 09:30, Roger Pau Monné wrote:
> > /*
> > * Explicitly list debug section for the PE output so that they don't
> > * end up at VA 0 which is below image base and thus invalid. Also use
> > * the NOLOAD directive, even wh
On Fri, Apr 16, 2021 at 04:20:59PM +0200, Jan Beulich wrote:
> On 16.04.2021 15:41, Andrew Cooper wrote:
> > On 16/04/2021 09:16, Jan Beulich wrote:
> >> clang, at the very least, doesn't like unused inline functions, unless
> >> their definitions live in a header.
> >>
> >> Fixes: d23d792478 ("x86
On 23.04.2021 11:43, Roger Pau Monne wrote:
> Clang reports the following build error without CONFIG_PV:
>
> hypercall.c:253:10: error: variable 'op' is used uninitialized whenever 'if'
> condition is false [-Werror,-Wsometimes-uninitialized]
> if ( !is_pv_32bit_vcpu(curr) )
> ^~
On Fri, Apr 23, 2021 at 11:43:43AM +0200, Roger Pau Monne wrote:
> Clang reports the following build error without CONFIG_PV:
s/CONFIG_PV/CONFIG_PV32/ on the line above, sorry.
Thanks, Roger.
On 23.04.2021 11:43, Roger Pau Monne wrote:
> Clang complains with:
>
> backtrace.c:46:19: error: unused function 'is_32bit_vcpu'
> [-Werror,-Wunused-function]
> static inline int is_32bit_vcpu(struct vcpu *vcpu)
> ^
>
> Fix this by guarding the function with CONFIG_COMPAT, as
Clang reports the following build error without CONFIG_PV:
hypercall.c:253:10: error: variable 'op' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]
if ( !is_pv_32bit_vcpu(curr) )
^~~
hypercall.c:282:21: note: uninitialize
Clang complains with:
backtrace.c:46:19: error: unused function 'is_32bit_vcpu'
[-Werror,-Wunused-function]
static inline int is_32bit_vcpu(struct vcpu *vcpu)
^
Fix this by guarding the function with CONFIG_COMPAT, as it's only
caller is also doing so.
Fixes: d23d792478d ('x86
Hello,
Two clang related build fixes to get the hypervisor building again with
clang without CONFIG_PV32.
Thanks, Roger.
Roger Pau Monne (2):
x86/oprofile: fix oprofile for clang build
x86/pv: fix clang build without CONFIG_PV32
xen/arch/x86/oprofile/backtrace.c | 2 ++
xen/arch/x86/pv/hy
On 21.04.2021 17:23, Andrew Cooper wrote:
> On 21/04/2021 15:54, Jan Beulich wrote:
>> In the long run I think we want to do away with these type-unsafe
>> interfaces, the more that they also request (typically) excess
>> alignment. This series of entirely independent patches is
>> eliminating the
On 19.03.21 21:01, Stefano Stabellini wrote:
From: Stefano Stabellini
Newer Xen versions expose two Xen feature flags to tell us if the domain
is directly mapped or not. Only when a domain is directly mapped it
makes sense to enable swiotlb-xen on ARM.
Introduce a function on ARM to check the
On 23.04.2021 09:30, Roger Pau Monné wrote:
> On Thu, Apr 22, 2021 at 06:01:06PM +0200, Jan Beulich wrote:
>> On 22.04.2021 17:53, Roger Pau Monné wrote:
>>> On Thu, Apr 22, 2021 at 05:46:28PM +0200, Jan Beulich wrote:
On 22.04.2021 16:56, Roger Pau Monné wrote:
> On Thu, Apr 22, 2021 at 0
flight 161398 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161398/
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 26.01.21 21:55, Bjorn Helgaas wrote:
From: Bjorn Helgaas
Fix misspelling of "physical".
Signed-off-by: Bjorn Helgaas
Pushed to xen/tip.git for-linus-5.13
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signatur
On 13.04.21 19:52, Boris Ostrovsky wrote:
Commit 76fc253723ad ("xen/acpi-stub: Disable it b/c the acpi_processor_add
is no longer called.") declared as BROKEN support for Xen ACPI stub (which
is required for xen-acpi-{cpu|memory}-hotplug) and suggested that this
is temporary and will be soon fixe
On 07.04.21 16:37, Jan Beulich wrote:
There's no point in comparing SBDF - we can simply compare the struct
pci_dev pointers. If they weren't the same for a given device, we'd have
bigger problems from having stored a stale pointer.
Signed-off-by: Jan Beulich
Pushed to xen/tip.git for-linus-5
On 26.03.21 19:14, Muhammad Usama Anjum wrote:
Correct enum pci_channel_io_normal should be used instead of putting
integer value 1.
Fix following smatch warnings:
drivers/xen/xen-pciback/pci_stub.c:805:40: warning: incorrect type in argument
2 (different base types)
drivers/xen/xen-pciback/pci
On 02.02.21 18:56, Paul Durrant wrote:
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a frontend was:
- read 'ring-page-order'
- i
On Thu, Apr 22, 2021 at 06:01:06PM +0200, Jan Beulich wrote:
> On 22.04.2021 17:53, Roger Pau Monné wrote:
> > On Thu, Apr 22, 2021 at 05:46:28PM +0200, Jan Beulich wrote:
> >> On 22.04.2021 16:56, Roger Pau Monné wrote:
> >>> On Thu, Apr 22, 2021 at 01:03:13PM +0200, Jan Beulich wrote:
> On 2
On Thu, Apr 22, 2021 at 04:14:53PM +0800, Claire Chang wrote:
> Fix the type of index from unsigned int to int since find_slots() might
> return -1.
>
> Fixes: 0774983bc923 ("swiotlb: refactor swiotlb_tbl_map_single")
> Signed-off-by: Claire Chang
Looks good:
Reviewed-by: Christoph Hellwig
it
> On 23 Apr 2021, at 08:00, Juergen Gross wrote:
>
> On 23.04.21 08:55, Luca Fancellu wrote:
>>> On 23 Apr 2021, at 06:40, Juergen Gross wrote:
>>>
>>> Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
>>> introduced an error in gntdev_mmap(): in case the call of
>>> mm
flight 161388 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161388/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On 23.04.21 08:55, Luca Fancellu wrote:
On 23 Apr 2021, at 06:40, Juergen Gross wrote:
Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
introduced an error in gntdev_mmap(): in case the call of
mmu_interval_notifier_insert_locked() fails the exit path should not
call m
95 matches
Mail list logo
