flight 172701 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172701/
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 Luca,
On 22/08/2022 07:56, Luca Fancellu wrote:
On 5 Aug 2022, at 18:35, Julien Grall wrote:
Hi Luca,
On 05/08/2022 14:08, Luca Fancellu wrote:
The function arch_set_info_guest is not reached anymore through
VCPUOP_initialise on arm, update the comment.
Signed-off-by: Luca Fancellu
--
On Mon, Aug 22, 2022 at 07:17:40AM +0200, Juergen Gross wrote:
> And then there is mtrr_state_warn() in arch/x86/kernel/cpu/mtrr/generic.c
> which has a comment saying:
>
> /* Some BIOS's are messed up and don't set all MTRRs the same! */
That thing also says:
pr_info("mtrr: probably you
On 22.08.22 10:28, Borislav Petkov wrote:
On Mon, Aug 22, 2022 at 07:17:40AM +0200, Juergen Gross wrote:
And then there is mtrr_state_warn() in arch/x86/kernel/cpu/mtrr/generic.c
which has a comment saying:
/* Some BIOS's are messed up and don't set all MTRRs the same! */
That thing also says
Hello,
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hypervisor agnostic Rust based backend [1].
This is based of orig
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Reviewed-by: Oleksandr Tyshchenko
Signed-off-b
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-gpio backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio Gpio:
gpio = [ "" ]
Please note, this patch is not enough for virtio-gpi
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
This also relocates the code responsible to call make_xen_iommu_node()
towards the end of the routine, so we create the node only once.
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 46 +---
1
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-i2c backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio I2c:
i2c = [ "" ]
Please note, this patch is not enough for virtio-i2c to
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one where the fdt node isn't closed and the
other one to create a
flight 172696 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172696/
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
On 21.08.2022 18:14, Marek Marczykowski-Górecki wrote:
> On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki wrote:
>> On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki wrote:
>>> On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
On 29.09.20 17:16
On 19.08.2022 21:43, Xenia Ragiadakou wrote:
> In macros dt_for_each_property_node(), dt_for_each_device_node() and
> dt_for_each_child_node(), add parentheses around the macro parameters that
> have the arrow operator applied, to prevent against unintended expansions.
Why is this relevant only wh
On Mon, Aug 22, 2022 at 11:53:50AM +0200, Jan Beulich wrote:
> On 21.08.2022 18:14, Marek Marczykowski-Górecki wrote:
> > On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki wrote:
> >> On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Sep 29
flight 172703 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172703/
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 Jan,
On 8/22/22 12:59, Jan Beulich wrote:
On 19.08.2022 21:43, Xenia Ragiadakou wrote:
In macros dt_for_each_property_node(), dt_for_each_device_node() and
dt_for_each_child_node(), add parentheses around the macro parameters that
have the arrow operator applied, to prevent against unintende
flight 172705 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172705/
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 22.08.2022 12:43, Xenia Ragiadakou wrote:
> On 8/22/22 12:59, Jan Beulich wrote:
>> On 19.08.2022 21:43, Xenia Ragiadakou wrote:
>>> In macros dt_for_each_property_node(), dt_for_each_device_node() and
>>> dt_for_each_child_node(), add parentheses around the macro parameters that
>>> have the ar
flight 172698 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172698/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 172679
test-amd64-amd64-pygrub
On 19.08.2022 12:02, Rahul Singh wrote:
> From: Julien Grall
>
> Since commit 01280dc19cf3 "evtchn: simplify port_is_valid()", the event
> channels code assumes that all the buckets below d->valid_evtchns are
> always allocated.
>
> This assumption hold in most of the situation because a guest i
early_page_fault() needs to outside of #ifdef CONFIG_PV
Spotted by Gitlab CI.
Fixes: fe3f50726e87 ("x86/entry: move .init.text section higher up in the code
for readability")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/x86_64/entry.S | 2
On 22.08.2022 15:12, Andrew Cooper wrote:
> early_page_fault() needs to outside of #ifdef CONFIG_PV
>
> Spotted by Gitlab CI.
>
> Fixes: fe3f50726e87 ("x86/entry: move .init.text section higher up in the
> code for readability")
> Signed-off-by: Andrew Cooper
Makes me wonder whether the origin
On 19.08.2022 12:02, Rahul Singh wrote:
> In a follow-up patch we will be able to either reserve or allocate a
> port for various event channel helpers.
Maybe "... we will want to ..."?
> A new wrapper is introduced to either reserved a given port or allocate
> an empty one if zero.
Maybe a/empt
On 19.08.2022 12:02, Rahul Singh wrote:
> Static event channel support will be added for dom0less domains.
> Restrict the maximum number of evtchn supported for domUs to avoid
> allocating a large amount of memory in Xen.
Please clarify here how you arrived at 4096 and why you expect no
dom0less D
On 19.08.2022 12:02, Rahul Singh wrote:
> Static event channel support will be added for dom0less domains. Modify
> evtchn_bind_interdomain to support static evtchn.
>
> It is necessary to have access to the evtchn_bind_interdomain function
> to do that, so make evtchn_bind_interdomain global and
On 19.08.2022 12:02, Rahul Singh wrote:
> evtchn_alloc_unbound() always allocates the next available port. Static
> event channel support for dom0less domains requires allocating a
> specified port.
>
> Modify the evtchn_alloc_unbound() to accept the port number as an
> argument and allocate the s
On 7/29/22 17:50, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Xen toolstack has gained basic Virtio support recently which becides
> adding various virtio related stuff introduces new disk backend type
> LIBXL_DISK_BACKEND_STANDALONE [1].
>
> Unfortunately, this caused a regress
On 8/19/22 11:57, Anthony PERARD wrote:
> On Mon, Aug 01, 2022 at 10:23:48AM +0200, Michal Prívozník wrote:
>> Ah, I couldn't find the commit in master, and it's simply because it's
>> not there yet. It's in staging:
>>
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;f=tools/libs/light/libxl_
flight 172707 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172707/
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
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
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
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 allows configuring EHCI and XHCI consoles separately,
simultaneously.
Suggested-by: Jan Beulich
Signed-off-by: Marek Marczykowski-Górecki
---
new in v5
---
docs/misc/xen-command-line.pandoc | 18 --
xen/drivers/char/serial.c | 6 ++
xen/drivers/char/xhci-dbc.c
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
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
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
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
When cable is unplugged, dbc_ensure_running() correctly detects this
situation (DBC_CTRL_DCR flag is clear), and prevent sending data
immediately to the device. It gets only queued in work ring buffers.
When cable is plugged in again, subsequent dbc_flush() will send the
buffered data.
But there is
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
On 21.08.22 18:14, Marek Marczykowski-Górecki wrote:
On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki wrote:
On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki wrote:
On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
On 29.09.20 17:16, Marek Mar
flight 172708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172708/
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 172700 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172700/
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
flight 172699 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172699/
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
flight 172702 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172702/
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 172710 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172710/
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
arch_domain_create() can't blindly write into d->arch.hvm union. Move the
logic into hvm_domain_initialise(), which involves passing config down.
Fixes: 2ce11ce249a3 ("x86/HVM: allow per-domain usage of hardware virtualized
APIC")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau
flight 172715 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172715/
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 172706 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172706/
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 172709 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 172698
test-amd64-amd64-q
flight 172717 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172717/
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 172712 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172712/
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
flight 172714 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172714/
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 172721 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172721/
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
I build and run it on armv8a, and start dom0 with two cpus. Cpu off and on
tests passed. It seems it don't break current cpu basic functions.
Best wishes
Jiamei Xie
> -Original Message-
> From: Xen-devel On Behalf Of
> Jens Wiklander
> Sent: Thursday, August 18, 2022 6:56 PM
> To:
While the SDM isn't very clear about this, our present behavior make
Linux 5.19 unhappy. As of commit 8ad7e8f69695 ("x86/fpu/xsave: Support
XSAVEC in the kernel") they're using this CPUID output also to size
the compacted area used by XSAVEC. Getting back zero there isn't really
liked, yet fpr PV t
56 matches
Mail list logo
