> From: Jan Beulich
> Sent: Wednesday, June 23, 2021 2:52 PM
>
> On 09.06.2021 11:25, Jan Beulich wrote:
> > A number of further adjustments were left out of the XSA, for not
> > being a security concern (anymore in some of the cases, with the
> > changes put in place there). This is the collecti
On 09.06.2021 11:25, Jan Beulich wrote:
> A number of further adjustments were left out of the XSA, for not
> being a security concern (anymore in some of the cases, with the
> changes put in place there). This is the collection, possibly
> looking a little random in what it contains.
>
> 1: AMD/I
flight 162985 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162985/
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 22.06.2021 20:25, Andrew Cooper wrote:
> On 22/06/2021 16:19, Jan Beulich wrote:
>> There's no xencall6(), so the version script also shouldn't mention it.
>> If such a function would ever appear, it shouldn't land in version 1.0.
>>
>> Signed-off-by: Jan Beulich
>> Acked-by: Ian Jackson
>
>
flight 162972 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 162968 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162968/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
I figured it out. Microsoft did not document that testsigning needs to be
enabled for kdnet to work.
On Tue, Jun 22, 2021 at 2:12 PM Tamas K Lengyel
wrote:
> Make sure windbg is already waiting for the connection from the
> debugee by the time Windows starts booting. If you try to attach
> windb
Hi Rahul,
Do you have an opinion on how we should move forward on this?
Do you think it is OK to go for a full revert of "xen/arm: smmuv1:
Intelligent SMR allocation" or do you think it is best to go with an
alternative fix? If so, do you have something in mind?
On Tue, 15 Jun 2021, Stefano St
On Sat, 19 Jun 2021, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
> Tested-by: Stefano Stabellini
> Tested-by: Will Deacon
Acked-by: Ste
flight 162977 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162977/
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 22/06/2021 16:19, Jan Beulich wrote:
> Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in
> particular, can return values requiring more than 31 bits to represent.
> Hence we cannot issue the hypercall directly when the return value of
> ioctl() is used to propagate this valu
On 22/06/2021 16:20, Jan Beulich wrote:
> libxc generally uses uint32_t to represent domain IDs. This is fine as
> long as addresses of such variables aren't taken, to then pass into
> hypercalls: To the hypervisor, a domain ID is a 16-bit value. Introduce
> a wrapper struct to deal with the issue.
On 22/06/2021 16:19, Jan Beulich wrote:
> There's no xencall6(), so the version script also shouldn't mention it.
> If such a function would ever appear, it shouldn't land in version 1.0.
>
> Signed-off-by: Jan Beulich
> Acked-by: Ian Jackson
Reviewed-by: Andrew Cooper
This really does need ba
On 22/06/2021 16:18, Jan Beulich wrote:
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values.
>
> Signed-off-by: Jan Beulich
> Acked-by: Ian Jackson
Acked-by: Andr
In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.
This causes the code to be noticed by CI, which objects as follows:
test-xenstore.c: In function 'main':
test-xenstore.c:486:5: error: ignoring return value of 'asprintf', declared
with
In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.
Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.
Signed-off-
In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.
Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulic
mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases. Drop the test infrasturcture.
Move the one useful remaining item, xen-mceinj, into misc/, fixing some minor
style issues as it goes.
v2:
* Fix CI failures from newly-exposed logic
* Drop -f's from $(RM)
* Drop the 'run' rune patch. Its clearly controvertial, but ignoring the
problems isn't an available option in the longterm.
All other RFC questions still outstanding.
Andrew Cooper (4):
tools/tests: Drop obsolete mce-
Make sure windbg is already waiting for the connection from the
debugee by the time Windows starts booting. If you try to attach
windbg later it won't work. It worked for me but obviously YMMV.
Tamas
On Tue, Jun 22, 2021 at 2:07 PM Neil Sikka wrote:
>
> I tried that, but it seems like I'm gettin
I tried that, but it seems like I'm getting an interrupt storm on the
debugger VM (CPU spends all its time in the kernel) when I try to attach
the debugger. This observation furthers my suspicion that there is
communication, but there is something wrong with the protocol...
On Tue, Jun 22, 2021 at
On 6/22/21 5:38 AM, Zhu Lingshan wrote:
> -static int xen_is_user_mode(void)
> -{
> - const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
> + state |= PERF_GUEST_ACTIVE;
>
> - if (!xenpmu_data) {
> - pr_warn_once("%s: pmudata not initialized\n", __func__);
> -
Goes through all the drivers and deletes the default hook since it's
the default now.
Acked-by: David Lechner
Acked-by: Noralf Trønnes
Acked-by: Oleksandr Andrushchenko
Acked-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes"
Cc: Linus W
I used Xen 4.15 and a pretty new version of Windows 10. It is a bit
finicky, you have to run the debug commands on the debugee and then
reboot. When the VM is rebooting the domain ID changes so you have to
start the serial bridge then. Windbg will attach afterwards. Just make
sure both VMs have ser
Hi Oleksandr,
On 14/06/2021 21:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "renesas,r8a77961" string identifies M3-W+ (aka M3-W ES3.0)
instead of "renesas,r8a7796" since Linux commit:
"9c9f7891093b02eb64ca4e1c7ab776a4296c058f soc: renesas: Identify R-Car M3-W+".
Add new comp
Thanks for the quick response, Tamas. I tried what you said and windbg
waits and the debugee hangs when I click the break button in windbg, but I
don't see any output in windbg. This means that there is SOME communication
over the serial port that causes the debugee to hang when I click break.
Coul
On 22/06/2021 17:10, Jan Beulich wrote:
> On 22.06.2021 17:39, Andrew Cooper wrote:
>> This reverts commit aad7b5c11d51d57659978e04702ac970906894e8.
>>
>> The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby
>> OvmfXen maps its shared info page at the top of address space. When
Patch ping.
On Fri, May 7, 2021 at 11:28 AM Tamas K Lengyel wrote:
>
> Signed-off-by: Tamas K Lengyel
> ---
> tools/misc/Makefile | 2 +-
> tools/misc/xen-vmtrace.c | 12 +---
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/tools/misc/Makefile b/tools/misc/Mak
On 22.06.2021 17:39, Andrew Cooper wrote:
> This reverts commit aad7b5c11d51d57659978e04702ac970906894e8.
>
> The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby
> OvmfXen maps its shared info page at the top of address space. When trying to
> migrate such a domain, XENMEM_ma
I have managed to get windbg working with a serial bridge between two
Win10 VMs using the following script:
https://github.com/intel/kernel-fuzzer-for-xen-project/blob/master/scripts/serial-bridge.sh.
The debugee has to enable a couple options so that windbg can attach:
https://github.com/intel/ker
Hello,
Has anyone gotten a Windows10 (Version 1709 of later) kernel debugger
attached when running the Windows10 debugger VM and the Windows10 debugee
VM on Xen 4.13.0 hypervisor? I am getting a "NIC hardware initialization
failed" error. I tried the suggestions in the discussion here (
https://bug
On Tue, Jun 22, 2021 at 04:39:30PM +0100, Andrew Cooper wrote:
> This reverts commit aad7b5c11d51d57659978e04702ac970906894e8.
>
> The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby
> OvmfXen maps its shared info page at the top of address space. When trying to
> migrate suc
This reverts commit aad7b5c11d51d57659978e04702ac970906894e8.
The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby
OvmfXen maps its shared info page at the top of address space. When trying to
migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This
has unc
flight 162973 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162973/
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
libxc generally uses uint32_t to represent domain IDs. This is fine as
long as addresses of such variables aren't taken, to then pass into
hypercalls: To the hypervisor, a domain ID is a 16-bit value. Introduce
a wrapper struct to deal with the issue. (On architectures with
arguments passed in regi
There's no xencall6(), so the version script also shouldn't mention it.
If such a function would ever appear, it shouldn't land in version 1.0.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Split out of earlier patch.
--- a/tools/libs/call/libxencall.map
+++ b/tools/libs/call/libxenc
Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in
particular, can return values requiring more than 31 bits to represent.
Hence we cannot issue the hypercall directly when the return value of
ioctl() is used to propagate this value (note that this is not the case
for the BSDs,
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Move dropping of xencall6 from the version script to a sep
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values. (Note that for Solaris the
function also gets renamed, to match the other OSes.)
Due to them merely propagating ioctl
To be able to use them from, in particular, the tool stack, they need to
be supported for all guest types. Note that xc_resource_op() already
does, so would not work without this on PVH Dom0.
Signed-off-by: Jan Beulich
Begrudingly acked-by: Andrew Cooper
Acked-by: Ian Jackson
--- a/xen/arch/x8
The present remaining osstest failures are due to truncation of the GFN
resulting from the hypercall return value being passed back through the
ioctl() return value (on Linux and Solaris), which is "int", plus the
same for some further internal interfaces (osdep_hypercall(),
xencall()). Some of the
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut
This commit is dedicated to fix incorrect conversion from
cpu_addr to page address in cases when we get virtual
address which allocated in the vmalloc range.
As the result, virt_to_page() cannot convert this address
properly and return incorrect page address.
Need to detect such cases and obtains
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interr
Jan Beulich writes ("[PATCH 3/5] libxencall: introduce variant of xencall2()
returning long"):
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values.
Thanks for this
flight 162956 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/162956/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-i386
flight 162958 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/162958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 162952 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/162952/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvop
flight 162948 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/162948/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 162963 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/162963/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xtf broken
build-arm64
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index bc658006..9a405444 100644
--- a/production-config
+++ b/production-config
@@ -91,7 +91,7 @@ TftpNetbootGroup osstest
TftpDiVersion_whee
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[7.581000] [ cut here ]
[7.581899] Interrupt for port 19, but apparently not enabled;
per-user 4af23acc
[7.583401] WARNING: CP
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could m
From: Like Xu
For "struct perf_guest_info_callbacks", the two fields "is_in_guest"
and "is_user_mode" are replaced with a new multiplexed member named
"state", and the "get_guest_ip" field will be renamed to "get_ip".
For arm64, xen and kvm/x86, the application of DEFINE_STATIC_CALL_RET0
could m
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored because do_lu_start() assumes
lu_status will be valid. This i
On 22.06.21 10:53, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 10:46, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Cu
Hi Juergen,
On 22/06/2021 10:46, Juergen Gross wrote:
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored becau
On 17.06.21 19:38, Julien Grall wrote:
From: Julien GralL
As Live-Update is asynchronous, it is possible to receive a request to
cancel it (either on the same connection or from a different one).
Currently, this will crash xenstored because do_lu_start() assumes
lu_status will be valid. This i
flight 162943 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162943/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
flight 162960 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162960/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-arm64-xs
62 matches
Mail list logo
