Good morning, I hope the week is starting well for everyone.
We've made extensive use of PCI based graphics pass through for many
years, since around Xen 4.2. In fact, we maintained a set of patches
for ATI cards against qemu-traditional that have seen a lot of
downloads from our FTP site.
We en
On 11.02.22 17:44, Roger Pau Monné wrote:
> On Fri, Feb 11, 2022 at 12:13:38PM +, Oleksandr Andrushchenko wrote:
>>
>> On 11.02.22 13:40, Roger Pau Monné wrote:
>>> On Fri, Feb 11, 2022 at 07:27:39AM +, Oleksandr Andrushchenko wrote:
Hi, Roger!
On 10.02.22 18:16, Roger Pau
flight 168103 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168103/
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-pvops
From: Stefano Stabellini
Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domain which is using the host memory layout
Considering that DOM0 may not always be directly mapped in the f
From: Stefano Stabellini
This commit creates a new doc to document how to do passthrough without IOMMU.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Tested-by: Stefano Stabellini
---
v2 changes:
- nothing changed
---
v3 changes:
- nothing changed
---
v4
This commit gates function make_gicv3_domU_node with CONFIG_GICV3.
Signed-off-by: Penny Zheng
Acked-by: Stefano Stabellini
Tested-by: Stefano Stabellini
---
v4 changes:
- remove ASSERT_UNREACHABLE() to avoid breaking compilation on prod build with
CONFIG_GICV3=n
---
v5 changes:
- nothing change
From: Stefano Stabellini
We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.
So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.
Do the same for the virtual IRQ
Helper allocate_static_memory is not meant to be reachable when built with
!CONFIG_STATIC_MEMORY, so this commit adds ASSERT_UNREACHABLE in it to catch
potential misuse.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Tested-by: Stefano Stabellini
---
v3 changes:
- new commit
---
v4 changes:
From: Stefano Stabellini
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domains that are direct-mapped.
NEW VGIC has different naming schemes, like referring distributor base
addres
Cases where domU needs direct-map memory map:
* IOMMU not present in the system.
* IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be totally
"direct-map" property shall be added under the appropriate domain node,
when users requesting direct-map memory mapping for the domain.
Right now, direct-map is only supported when domain on Static Allocation,
that is, "xen,static-mem" is also necessary in the domain configuration.
Looking into r
From: Stefano Stabellini
At the moment, we are only supporting device-passthrough when Xen has
enabled the IOMMU. There are some use cases where it is not possible to
use the IOMMU (e.g. doesn't exist, hardware limitation, performance) yet
it would be OK to assign a device to trusted domain so lo
Later, we will introduce assign_static_memory_11 for allocating static
memory for direct-map domains, and it will share a lot common codes with
the existing allocate_static_memory.
In order not to bring a lot of duplicate codes, and also to make the whole
code more readable, this commit extracts c
From: Stefano Stabellini
This commit introduces a new arm-specific flag CDF_directmap to specify
that a domain should have its memory direct-map(guest physical address
== host physical address) at domain creation.
Also, add a directmap flag under struct arch_domain and use it to
reimplement is_d
From: Stefano Stabellini
We are passing an internal-only boolean flag at domain creation to
specify whether we want the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.
This commit extends original "boolean" to an "unsigned int" covering both
the
flight 168102 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168102/
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-pvops
>>On Thu, Feb 10, 2022 at 06:30:23PM -0800, Qing Wang wrote:
>> From: Wang Qing
>>
>> It is better to use time_is_xxx() directly instead of jiffies judgment
>> for understanding.
>
>Hi Wang,
>
>"judgement" doesn't really make sense as a description to an English
>speaker. The following a commi
flight 168101 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168101/
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-pvops
flight 168099 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168099/
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-pvops
On 13.02.22 18:06, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/02/2022 16:55, Oleksandr wrote:
>>
>> On 10.02.22 11:46, Julien Grall wrote:
>>>
>>>
>>> On 08/02/2022 19:50, Oleksandr Tyshchenko wrote:
On 08.02.22 13:58, Julien Grall wrote:
Below the diff I have loca
flight 168097 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168097/
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-pvops
Hi Oleksandr,
On 10/02/2022 16:55, Oleksandr wrote:
On 10.02.22 11:46, Julien Grall wrote:
On 08/02/2022 19:50, Oleksandr Tyshchenko wrote:
On 08.02.22 13:58, Julien Grall wrote:
Below the diff I have locally:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5646343..90d7563 100
flight 168096 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168096/
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-pvops
flight 168098 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168098/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Hi,
On 12/02/2022 23:34, Ayan Kumar Halder wrote:
xen/arch/arm/arm32/traps.c| 7 +++
xen/arch/arm/arm64/traps.c| 47 +++
xen/arch/arm/decode.c | 1 +
xen/arch/arm/include/asm/domain.h | 4 ++
xen/arch/arm/include/asm/mmio.h | 15 -
xen/arc
flight 168095 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168095/
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-pvops
flight 168100 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168100/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 87319afb96973213ec0a76270d93696f3b8d6743
baseline version:
xen 52ce
27 matches
Mail list logo
