flight 172453 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172453/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 broken
build-i386-libvirt6 libvirt-buil
flight 172469 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172442 xen-unstable real [real]
flight 172465 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172442/
http://logs.test-lab.xenproject.org/osstest/logs/172465/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-
flight 172461 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172445 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
That's possible, because the capability was designed specifically to
allow separate driver handle it, in parallel to unmodified xhci driver
(separate set of registers, pretending the port is "disconnected" for
the main xhci driver etc). It works with Linux dom0, although requires
an awful hack - re
The important part is to include those buffers in IOMMU page table
relevant for the USB controller. Otherwise, DbC will stop working as
soon as IOMMU is enabled, regardless of to which domain device assigned
(be it xen or dom0).
If the device is passed through to dom0 or other domain (see later
pat
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- make MAX_USER_RMRR_PAGES applicable only to user-configured RMRR
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file change
This is integration of https://github.com/connojd/xue into mainline Xen.
This patch series includes several patches that I made in the process, some are
very loosely related.
The driver developed by Connor supports console via USB3 debug capability. The
capability is designed to operate mostly ind
From: Connor Davis
[Connor]
Xue is a cross-platform USB 3 debugger that drives the Debug
Capability (DbC) of xHCI-compliant host controllers. This patch
implements the operations needed for xue to initialize the host
controller's DbC and communicate with it. It also implements a struct
uart_drive
Previously only one serial console was supported at the same time. Using
console=com1,dbgp,vga silently ignored all but last serial console (in
this case: only dbgp and vga were active).
Fix this by storing not a single sercon_handle, but an array of them, up
to MAX_SERCONS entries. The value of M
It doesn't modify it, and it will be necessary in a subsequent patch.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/serial.c | 2 +-
xen/include/xen/serial.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/seri
Reset ports, to force host system to re-enumerate devices. Otheriwse it
will require the cable to be re-plugged, or will wait in the
"configuring" state indefinitely.
Trick and code copied from Linux:
drivers/usb/early/xhci-dbc.c:xdbc_start()->xdbc_reset_debug_port()
Signed-off-by: Marek Marczyko
Add another work ring buffer for received data, and point IN TRB at it.
Ensure there is always at least one pending IN TRB, so the controller
has a way to send incoming data to the driver.
Note that both "success" and "short packet" completion codes are okay -
in fact it will be "short packet" most
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Jan Beulich
---
Changes in v3:
- use variable initializer
- use pfn_to_paddr()
---
xen/drivers/passthrough/amd/iommu_acpi.c | 21 +
1 file
Add API similar to rmrr= and ivmd= arguments, but in a common code. This
will allow drivers to register reserved memory regardless of the IOMMU
vendor.
The direct reason for this API is xhci-dbc console driver (aka xue),
that needs to use DMA. But future change may unify command line
arguments for
Handle parameters similar to dbgp=ehci.
Implement this by not resettting dbc->sbdf again in dbc_init_xhc(), but
using a value found there if non-zero. Additionally, add xue->xhc_num to
select n-th controller.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
---
Changes in v4:
Add SPDX license information to all the *.c files under arch/arm.
Signed-off-by: Stefano Stabellini
---
We need to start from somewhere and I thought arch/arm/*.c would be a
good place to start.
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index f03cd943c6..8115f89408 10
flight 172455 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172435 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172449 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172449/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172422 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172446 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172446/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
From: Julien Grall
Unlike arm64, on arm32 there are no extra information dumped (e.g.
page table walk) for hypervisor data abort.
For data abort, the HSR will be set properly and so replace the call
to do_unexpected_trap() with do_trap_hyp_sync() to dispatch the error.
Signed-off-by: Julien Gra
From: Julien Grall
Unlike arm64, on arm32 there are no extra information dumped (e.g.
page table walk) for hypervisor data abort.
For data abort, the HSR will be set properly and so replace the call
to do_unexpected_trap() with do_trap_hyp_sync() to dispatch the error.
Signed-off-by: Julien Gra
From: Julien Grall
Currently the output is looking like:
(XEN) 1ST[0x1] = 0x4015ff7f
(XEN) 2ND[0x1f] = 0x0050bfe00f7d
The content of the entries are not aligned making a bit trickier to
read (I appreciate this is a matter of taste).
Align the values by forcing the index to be alway
From: Julien Grall
At the moment, the strings are in text right after each use because
the instruction 'adr' has specific requirement on the location
and the compiler will forbid cross section label.
The macro 'adr_l' was recently reworked so the caller doesn't need
to know whether the MMU is on
From: Julien Grall
At the moment, the macro addr_l needs to know whether the caller
is running with the MMU on. This is fine today because there are
only two possible cases:
1) MMU off
2) MMU on and linked to the virtual address
This is still cumbersome to use for the developer as they need
to
From: Julien Grall
There are a few places in the code that need to find the slot
at a given page-table level.
So create a new macro get_table_slot() for that. This will reduce
the effort to figure out whether the code is doing the right thing.
Take the opportunity to use 'ubfx'. The only benefi
From: Julien Grall
Since commit 7e14a47e7c73 ("xen/arm64: head Rework and document
launch()"), the boot code is setting x22 but not read it.
So remove the two instructions setting x22 and update the documentation
to show x22 has no specific purpose.
Signed-off-by: Julien Grall
---
xen/arch/ar
From: Julien Grall
---
xen/arch/arm/arm32/head.S | 50 +++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index a558c2a6876e..a914ffab98a5 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/a
From: Julien Grall
There are a few places in the code that need to find the slot at a
given page-table level.
So create a new macro get_table_slot() for that. This will reduce
the effort to figure out whether the code is doing the right thing.
The new macro is using 'ubfx' (or 'lsr' for the fir
From: Julien Grall
Hi all,
This is another collection of patches that I accumulated while
reworking the boot code. I am not planning to target Xen 4.17
for the boot code (still working on it and it is risky). But I
the clean-ups and improvement patches could be.
Cheers,
Julien Grall (7):
xen
From: Julien Grall
Xen build system the symbolic link xen/arch/arm/efi/stub.c. So we want
to ignore it.
Fixes: 7f96859b0d00 ("xen: reuse x86 EFI stub functions for Arm")
Signed-off-by: Julien Grall
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index
flight 172443 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
* Always emit current. It's critically important.
* Do not render () for the symbol in guest context. It's
just line-noise. Instead, explicitly identify which Xen vs guest context.
* Try to tabulate the data, because there is often lots of it.
Signed-off-by: Andrew Cooper
Hi Juergen,
On 12/08/2022 11:56, Juergen Gross wrote:
On 12.08.22 11:13, Julien Grall wrote:
Hi Juergen,
On 08/08/2022 12:31, Juergen Gross wrote:
On 08.08.22 13:00, Julien Grall wrote:
This would break the use of xenstore-stubdom for such a setup.
I am not sure why it would break the use
flight 172431 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172431/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
flight 172414 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172414/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-x
flight 172438 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172408 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172408/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
On Fri, Aug 12, 2022 at 03:36:12PM +0200, Jan Beulich wrote:
> On 11.08.2022 18:48, Anthony PERARD wrote:
> > Setup proper dependencies with libacpi so we don't need to run "make
> > hvmloader" in the "all" target. ("build.o" new prerequisite isn't
> > exactly proper but a side effect of building t
flight 172429 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172405 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
On 11.08.2022 18:48, Anthony PERARD wrote:
> Rework dependencies of all objects. We don't need to add dependencies
> for headers that $(CC) is capable of generating, we only need to
> include $(DEPS_INCLUDE). Some dependencies are still needed so make
> knows to generate symlinks for them.
>
> We
On 11.08.2022 18:48, Anthony PERARD wrote:
> Setup proper dependencies with libacpi so we don't need to run "make
> hvmloader" in the "all" target. ("build.o" new prerequisite isn't
> exactly proper but a side effect of building the $(DSDT_FILES) is to
> generate the "ssdt_*.h" needed by "build.o".
On 12.08.2022 14:55, Andrew Cooper wrote:
> There's no point wasting time converting binaries back to asm source. Just
> use .incbin directly. Explain in head.S what these binaries are.
>
> Also, explicitly align the blobs. They contain 4-byte objects, and happen to
> be 4-byte aligned currentl
There's no point wasting time converting binaries back to asm source. Just
use .incbin directly. Explain in head.S what these binaries are.
Also, explicitly align the blobs. They contain 4-byte objects, and happen to
be 4-byte aligned currently because of the position of `lret` and the size of
flight 172424 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 12.08.22 12:27, SHARMA, JYOTIRMOY wrote:
[AMD Official Use Only - General]
Hello Christopher,
Hello Jyotirmoy, Christopher
Just spotted that libxenbe and snd_be were mentioned ...
Thank you so much for your reply. I will execute your steps and first
try to enable pulse audio as you
flight 172409 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On 12.08.2022 11:53, Bertrand Marquis wrote:
>> On 9 Aug 2022, at 09:58, Penny Zheng wrote:
>>> -Original Message-
>>> From: Jan Beulich
>>> Sent: Tuesday, August 9, 2022 4:27 PM
>>>
>>> On 09.08.2022 10:07, Penny Zheng wrote:
> -Original Message-
> From: Jan Beulich
branch xen-unstable
xenbranch xen-unstable
job build-armhf-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.gi
On 12.08.22 11:13, Julien Grall wrote:
Hi Juergen,
On 08/08/2022 12:31, Juergen Gross wrote:
On 08.08.22 13:00, Julien Grall wrote:
This would break the use of xenstore-stubdom for such a setup.
I am not sure why it would break the use of xenstore-stubdom. An application
will already need t
Hi Juergen,
On 08/08/2022 12:31, Juergen Gross wrote:
And even with using an ID you'd have the same problem
again, but without having the possibility to add variant specific quota
Fair enough.
(remember that there already has been a statement that doing a live
update
from C to OCAML or vice
On 12/08/2022 07:45, Jan Beulich wrote:
> On 11.08.2022 18:37, Andrew Cooper wrote:
>> This reorders the fields in msi_info, but removes all the under-the-hood
>> parameter shuffling required to call pci_get_pdev().
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Oh, you've made t
flight 172415 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172415/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
On 16.07.22 00:51, SeongJae Park wrote:
Introduction of 'feature_persistent' made two bugs. First one is wrong
overwrite of 'vbd->feature_gnt_persistent' in 'blkback' due to wrong
parameter value caching position, and the second one is unintended
behavioral change that could break previous dynam
On 12/08/2022 08:29, Jan Beulich wrote:
> On 11.08.2022 21:59, Andrew Cooper wrote:
>> One source of lost performance was that fact that to protect Xen from a
>> malicious guests, we had to flush the RAS.
>>
>> It turns out that CET Shadow Stacks give us enough architectural guarantees
>> to
>> co
flight 172416 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Penny,
> On 9 Aug 2022, at 09:58, Penny Zheng wrote:
>
> Hi jan
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, August 9, 2022 4:27 PM
>> To: Penny Zheng
>> Cc: Wei Chen ; Andrew Cooper
>> ; George Dunlap ;
>> Julien Grall ; Stefano Stabellini ;
>> Wei Liu ; xen-deve
[AMD Official Use Only - General]
Hello Christopher,
Thank you so much for your reply. I will execute your steps and first try to
enable pulse audio as you have mentioned.
Later I will try to enable ALSA which is my final requirement.
Meanwhile, I was reading up on virtio-snd and found some pat
flight 172398 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
Hi Rahul,
On 11/08/2022 16:42, Rahul Singh wrote:
When devices are deassigned/assigned, SMMU global fault is observed
because SMEs are freed in detach function and not allocated again when
the device is assigned back to the guest.
Don't free the SMEs when devices are deassigned, set the s2cr to
The involved asm() expands to large enough a construct that often the
compiler would decide against inlining when a containing function is
used more than once in a CU. Use the "inline" keyword when supported by
the compiler in conjunction with asm().
The INIT_SECTIONS_ONLY dependency is because in
Hi Juergen,
On 08/08/2022 12:31, Juergen Gross wrote:
On 08.08.22 13:00, Julien Grall wrote:
This would break the use of xenstore-stubdom for such a setup.
I am not sure why it would break the use of xenstore-stubdom. An
application will already need to cope with the case Xenstored doesn't
show_hvm_stack() requires interrupts to be enabled to avoid triggering
the consistency check in check_lock() for the p2m lock. Add a respective
check. To avoid this check triggering when coming through
spurious_interrupt() requires adding reentrancy protection / handling
there alongside transiently
On 27.07.2022 20:25, Andrew Cooper wrote:
> On 26/07/2022 17:06, Jan Beulich wrote:
>> While "type" can include PGT_pae_xen_l2, "x" can't, as the bit is
>> cleared upon de-validation (see also the respective assertion earlier in
>> the function).
>
> While this statement is true, it doesn't really
On 10.08.22 07:07, Lukas Bulwahn wrote:
Commit 197ecb3802c0 ("xen/balloon: add runtime control for scrubbing
ballooned out pages") changed config XEN_SCRUB_PAGES to config
XEN_SCRUB_PAGES_DEFAULT. As xen.config sets 'XEN_BALLOON=y' and
XEN_SCRUB_PAGES_DEFAULT defaults to yes, there is no further
On 11.08.22 14:09, Jason Wang wrote:
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
On 10.08.22 07:07, Lukas Bulwahn wrote:
Make changes to the xen config fragments reach the XEN HYPERVISOR
maintainers and mailing list.
Signed-off-by: Lukas Bulwahn
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Descr
On 11 Aug 2022, at 17:48, Anthony PERARD
mailto:anthony.per...@citrix.com>> wrote:
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.toolstack-build-system-v4
Changes in v4:
- several new patches
- some changes to other patches list
For guests in shadow mode the P2M table gets used only by software. The
only place where it matters whether superpages in the P2M can be dealt
with is sh_unshadow_for_p2m_change(): The table is never made accessible
to hardware for address translation, and the only checks of _PAGE_PSE in
P2M entrie
In preparation for reactivating the presently dead 2M page path of the
function, also deal with the case of replacing an L1 page table all in
one go. Note that the prior comparing of MFNs to bypass the removal of
shadows was insufficient (but kind of benign, for being dead code so
far) - at the ver
Pull common checks out of the switch(). This includes extending a
_PAGE_PRESENT check to L1 as well, which presumably was deemed redundant
with p2m_is_valid() || p2m_is_grant(), but I think we are better off
being explicit in all cases. Note that for L2 (or higher) the grant
check isn't strictly ne
Replace a p2m_is_ram() check in the 2M case by an explicit _PAGE_PRESENT
one, to make more obvious that the subsequent l1e_get_mfn() actually
retrieves something that really is an MFN. It doesn't really matter
whether it's RAM, as the subsequent comparison with the original MFN is
going to lead to
I did notice this anomaly in the context of IOMMU side work.
1: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part I)
2: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part II)
3: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part III)
4: P2M: allow 2M superpa
On 11.08.2022 21:59, Andrew Cooper wrote:
> One source of lost performance was that fact that to protect Xen from a
> malicious guests, we had to flush the RAS.
>
> It turns out that CET Shadow Stacks give us enough architectural guarantees to
> construct a lower overhead mitigation, which keeps t
On 11.08.2022 21:59, Andrew Cooper wrote:
> A optimisation is going to want to conditionally have extra data on the stack
> around VMExit.
>
> We could alternative between `mov %rsp, %rdi` and `lea 8(%rsp), %rdi`, but it
> is easier just to make the functions void and let the compiler do the (not
81 matches
Mail list logo
