On 17.12.2022 21:17, Elliott Mitchell wrote:
> Note to Xen and Linux distribution maintainers: I suggest this needs a
> point release of Xen. A large processor manufacturer has recently
> released such a processor. A great number of people are going to be
> rather unhappy in short order without t
On 18.12.2022 01:18, Andrew Cooper wrote:
> On 17/12/2022 5:42 pm, Neowutran wrote:
>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>> index b01acd390d..7c77ec8902 100644
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -2585,7 +2585,7 @@ int tsc_set_info(struct domain *d,
On 16.12.2022 21:53, Andrew Cooper wrote:
> On 10/08/2022 3:06 pm, Jan Beulich wrote:
>> On 10.08.2022 15:36, Andrew Cooper wrote:
>>> From: Edwin Török
>>>
>>> Following on from cset 9ce0a5e207f3 ("x86/hvm: Improve hvm_set_guest_pat()
>>> code generation"), and the discovery that Clang/LLVM makes
On 16.12.2022 20:24, Andrew Cooper wrote:
> On 13/12/2022 11:36 am, Jan Beulich wrote:
>> RFC: With small enough a NUMA hash shift it would still be possible to
>> hit an SRAT hole, despite mfn_valid() passing. Hence, like was the
>> original plan, it may still be necessary to relax the c
flight 175396 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175396/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken in 175374
test-amd64-amd64-freebsd12-amd6
The function hvm_dpci_isairq_eoi() has no dependencies on VT-d driver code
and can be moved from xen/drivers/passthrough/vtd/x86/hvm.c to
xen/drivers/passthrough/x86/hvm.c.
Remove the now empty xen/drivers/passthrough/vtd/x86/hvm.c.
Since the funcion is hvm specific, move its declaration from xen
Use CONFIG_INTEL_VTD to guard their usage in common code.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/drivers/passthrough/iommu.c | 4 +++-
xen/include/xen/iommu.h | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrou
Posted interrupt support in Xen is currently implemented only for the
Intel platforms. Instead of calling directly pi_update_irte() from the
common hvm code, add a pi_update_irte callback to the hvm_function_table.
Then, create a wrapper function hvm_pi_update_irte() to be used by the
common hvm co
The functions acpi_dmar_init() and acpi_dmar_zap/reinstate() are
VT-d specific while the function acpi_ivrs_init() is AMD-Vi specific.
To eliminate dead code, they need to be guarded under CONFIG_INTEL_VTD
and CONFIG_AMD_IOMMU, respectively.
Instead of adding #ifdef guards around the function call
Currently, for x86 platforms, Xen does not provide to the users any
configuration control over the IOMMU support and can only be built with
both AMD and Intel IOMMU drivers enabled.
However, there are use cases, e.g in safety-critical systems, that require
Xen to be able to be configured to exclude
This series aims to provide a means to render the iommu driver support for x86
configurable. Currently, irrespectively of the target platform, both AMD and
Intel iommu drivers are built. This is the case because the existent Kconfig
infrastructure does not provide any facilities for finer-grained c
Move its definition to the AMD-Vi driver and use CONFIG_AMD_IOMMU
to guard its usage in common code.
Take the opportunity to replace bool_t with bool and 1 with true.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/drivers/passthrough/amd/iommu_init.c | 2 ++
xen/drivers
The variable untrusted_msi indicates whether the system is vulnerable to
CVE-2011-1898. This vulnerablity is VT-d specific.
Place the code that addresses the issue under CONFIG_INTEL_VTD.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/include/asm/iommu.h | 2 ++
flight 175398 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175398/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175394 qemu-mainline real [real]
flight 175397 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175394/
http://logs.test-lab.xenproject.org/osstest/logs/175397/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 175395 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175395/
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. 175202
test-amd64-amd64-xl-qemuu
On Sun, Dec 18, 2022 at 01:14:07PM +0100, Neowutran wrote:
> xen/x86: prevent overflow with high frequency TSCs
>
> Promote tsc_khz to a 64-bit type before multiplying by 1000 to avoid a
> 'overflow before widen' bug.
> Otherwise just above 4.294GHz the value will overflow.
> Processors with clock
flight 175391 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175391/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken in 175374
test-amd64-amd64-freebsd12-amd6
flight 175393 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175393/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175392/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175390 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175390/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175385 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken in 175374
test-amd64-amd64-xl-multivcpu
flight 175389 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175389/
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. 175202
test-amd64-amd64-xl-qemuu
xen/x86: prevent overflow with high frequency TSCs
Promote tsc_khz to a 64-bit type before multiplying by 1000 to avoid a
'overflow before widen' bug.
Otherwise just above 4.294GHz the value will overflow.
Processors with clocks this high are now in production and require this to work
correctly.
flight 175388 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175388/
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. 175202
test-amd64-amd64-xl-qemuu
flight 175383 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175383/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail in 175354
pass in 175383
test-amd64-amd64-li
flight 175387 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175387/
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. 175202
test-amd64-amd64-xl-qemuu
27 matches
Mail list logo
