On 03.10.2022 15:44, Andrew Cooper wrote:
> On 29/09/2022 11:03, Jan Beulich wrote:
>> Like done previously for the hypervisor and elsewhere.
>>
>> 1: suppress GNU ld 2.39 warning about RWX load segments
>> 2: silence GNU ld 2.39 warning about executable stacks
>
> I've taken these, and dropped th
On 03.10.2022 23:21, Andrew Cooper wrote:
> While working on another issue, I spotted this:
>
> (XEN) ACPI: EINJ 6CB9D638, 0150 (r1 ORACLE X7-2 41060300 INTL 1)
> (XEN) System RAM: 32429MB (33208204kB)
> (XEN) SRAT: Node 0 PXM 0 [, 7fff]
> (XEN) SRAT: Node 0
flight 173411 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173411/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173405
test-amd64-amd64-xl-qemuu-ws16-amd64
On 30.09.2022 16:28, Roger Pau Monné wrote:
> On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
>> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>> higher priority than the type of the range. To avoid accessing memory at
>> runtime which was re-used for other p
On 01.10.2022 02:30, Demi Marie Obenour wrote:
> On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote:
>> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour wrote:
>>> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
I know very little about Xen, but based on the contex
Hey Nadav,
On 03.10.22 19:34, Nadav Amit wrote:
On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
Not my but rather PCI maintainer's call but IMHO dropping 'const' is
better, introducing a new global var is our 'last resort' and should be
avoided whenever possible. Alternatively, you can ad
Nadav Amit writes:
> On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
>
>> Not my but rather PCI maintainer's call but IMHO dropping 'const' is
>> better, introducing a new global var is our 'last resort' and should be
>> avoided whenever possible. Alternatively, you can add a
>> raw_pci_ext_
On 30.09.2022 23:02, Demi Marie Obenour wrote:
> As discussed on xen-devel, using EfiRuntimeServicesData for more than is
> absolutely necessary is a bad idea.
> ---
> xen/common/efi/boot.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/xen/common/ef
Historically when running as Xen PV guest all MSR accesses have been
silently swallowing any GP faults, even when the kernel was using not
the *msr_safe() access functions.
Change that by making the behavior controllable via kernel config and
via a boot parameter.
This will help finding paths whe
Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
of read/write MSR in case the MSR access isn't emulated via Xen. Allow
the caller to select the potentially faulting variant by passing NULL
for the error pointer.
Restructure the code to make it more readable.
Signed-off-by:
Instead of always doing the safe variants for reading and writing MSRs
in Xen PV guests, make the behavior controllable via Kconfig option
and a boot parameter.
The default will be the current behavior, which is to always use the
safe variant.
Signed-off-by: Juergen Gross
---
.../admin-guide/ke
Refactor and rename xen_read_msr_safe() and xen_write_msr_safe() to
support both cases of MSR accesses, safe ones and potentially GP-fault
generating ones.
This will prepare to no longer swallow GPs silently in xen_read_msr()
and xen_write_msr().
Signed-off-by: Juergen Gross
---
V2:
- init val i
On 30.09.2022 16:17, Roger Pau Monne wrote:
> The EFI memory map contains two memory types (EfiMemoryMappedIO and
> EfiMemoryMappedIOPortSpace) used to describe IO memory areas of
> devices used by EFI.
>
> The current parsing of the EFI memory map was translating
> EfiMemoryMappedIO and EfiMemory
On 03.10.2022 23:21, Andrew Cooper wrote:
> While working on another issue, I spotted this:
>
> (XEN) ACPI: EINJ 6CB9D638, 0150 (r1 ORACLE X7-2 41060300 INTL 1)
> (XEN) System RAM: 32429MB (33208204kB)
> (XEN) SRAT: Node 0 PXM 0 [, 7fff]
> (XEN) SRAT: Node 0
On Tue, Oct 04, 2022 at 11:01:18AM +0200, Jan Beulich wrote:
> On 30.09.2022 16:17, Roger Pau Monne wrote:
> > The EFI memory map contains two memory types (EfiMemoryMappedIO and
> > EfiMemoryMappedIOPortSpace) used to describe IO memory areas of
> > devices used by EFI.
> >
> > The current parsin
On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
> On 30.09.2022 16:28, Roger Pau Monné wrote:
> > On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
> >> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
> >> higher priority than the type of the range.
Hi Jan,
On 28/09/2022 11:38, Jan Beulich wrote:
For quite some time we've been talking about replacing the present virtual
address based hypercall interface with one using physical addresses. This is in
particular a prerequisite to being able to support guests with encrypted
memory, as for such
On 04.10.2022 11:38, Julien Grall wrote:
> On 28/09/2022 11:38, Jan Beulich wrote:
>> Another approach would be to build in a scatter/gather model for buffers
>> right
>> away. Jürgen suggests that the low two address bits could be used as a
>> "descriptor" here.
>
> IIUC, with this approach we
Hi Viresh,
Apologies for the late reply. I was away for the past 2 weeks.
On 20/09/2022 11:29, Viresh Kumar wrote:
On 09-09-22, 16:02, Anthony PERARD wrote:
On Fri, Sep 09, 2022 at 08:13:28PM +0530, Viresh Kumar wrote:
The iommu node will be required for other virtio device types too, not
jus
As it turns out populate_memnodemap() so far "relied" on
extract_lsb_from_nodes() setting memnodemapsize one too high in edge
cases. Correct the issue there as well, by changing "epdx" to be an
inclusive PDX and adjusting the respective relational operators.
While there also limit the scope of bot
On 04.10.2022 11:33, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
>> On 30.09.2022 16:28, Roger Pau Monné wrote:
>>> On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>>
On Tue, Oct 04, 2022 at 12:13:49PM +0200, Jan Beulich wrote:
> As it turns out populate_memnodemap() so far "relied" on
> extract_lsb_from_nodes() setting memnodemapsize one too high in edge
> cases. Correct the issue there as well, by changing "epdx" to be an
> inclusive PDX and adjusting the resp
On Tue, Oct 04, 2022 at 12:23:23PM +0200, Jan Beulich wrote:
> On 04.10.2022 11:33, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
> >> On 30.09.2022 16:28, Roger Pau Monné wrote:
> >>> On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
> efi_
On 04.10.2022 11:27, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 11:01:18AM +0200, Jan Beulich wrote:
>> On 30.09.2022 16:17, Roger Pau Monne wrote:
>>> The EFI memory map contains two memory types (EfiMemoryMappedIO and
>>> EfiMemoryMappedIOPortSpace) used to describe IO memory areas of
>>> d
On 04.10.2022 12:38, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 12:23:23PM +0200, Jan Beulich wrote:
>> On 04.10.2022 11:33, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
On 30.09.2022 16:28, Roger Pau Monné wrote:
> On Fri, Sep 30, 2022 at 0
On 04/10/2022 11:23, Jan Beulich wrote:
> On 04.10.2022 11:33, Roger Pau Monné wrote:
>> On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
>>> On 30.09.2022 16:28, Roger Pau Monné wrote:
On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
> efi_init_memory() in both rel
On Tue, Oct 04, 2022 at 12:44:16PM +0200, Jan Beulich wrote:
> On 04.10.2022 12:38, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 12:23:23PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 11:33, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
> On 3
On 04.10.2022 10:43, Juergen Gross wrote:
> Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
> of read/write MSR in case the MSR access isn't emulated via Xen. Allow
> the caller to select the potentially faulting variant by passing NULL
> for the error pointer.
>
> Restruct
On 04.10.2022 10:43, Juergen Gross wrote:
> Refactor and rename xen_read_msr_safe() and xen_write_msr_safe() to
> support both cases of MSR accesses, safe ones and potentially GP-fault
> generating ones.
>
> This will prepare to no longer swallow GPs silently in xen_read_msr()
> and xen_write_msr(
On 04.10.2022 12:49, Andrew Cooper wrote:
> On 04/10/2022 11:23, Jan Beulich wrote:
>> On 04.10.2022 11:33, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 10:06:36AM +0200, Jan Beulich wrote:
On 30.09.2022 16:28, Roger Pau Monné wrote:
> On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Be
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [PATCH][4.17] x86/NUMA: correct off-by-1 in node map population
>
> As it turns out populate_memnodemap() so far "relied" on
> extract_lsb_from_nodes() setting memnodemapsize one too high in edge
> cases. Correct the issue there
flight 173413 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173413/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173392
test-armhf-armhf-libvirt-raw 15 saveresto
flight 173412 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173412/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-xsm 20 guest-localmigrate/x10 fail in 173402 pass in 173412
test-amd64-i386-livepatch 7
On Tue, Oct 04, 2022 at 12:13:49PM +0200, Jan Beulich wrote:
> As it turns out populate_memnodemap() so far "relied" on
> extract_lsb_from_nodes() setting memnodemapsize one too high in edge
> cases. Correct the issue there as well, by changing "epdx" to be an
> inclusive PDX and adjusting the resp
On Tue, Oct 04, 2022 at 12:40:10PM +0200, Jan Beulich wrote:
> On 04.10.2022 11:27, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 11:01:18AM +0200, Jan Beulich wrote:
> >> On 30.09.2022 16:17, Roger Pau Monne wrote:
> >>> The EFI memory map contains two memory types (EfiMemoryMappedIO and
> >>
On 04.10.2022 12:54, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 12:44:16PM +0200, Jan Beulich wrote:
>> On 04.10.2022 12:38, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 12:23:23PM +0200, Jan Beulich wrote:
On 04.10.2022 11:33, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 1
On 04.10.2022 14:17, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 12:40:10PM +0200, Jan Beulich wrote:
>> On 04.10.2022 11:27, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 11:01:18AM +0200, Jan Beulich wrote:
On 30.09.2022 16:17, Roger Pau Monne wrote:
> The EFI memory map contai
On 03.10.2022 13:20, Andrew Cooper wrote:
> On 29/09/2022 11:07, Jan Beulich wrote:
>> On 27.09.2022 17:47, Andrew Cooper wrote:
>>> This breaks all Clang builds, as demostrated by Gitlab CI.
>>>
>>> Contrary to the description in ecd6b9759919, -no-pie is not even an option
>>> passed to the linker
On Tue, Oct 04, 2022 at 02:18:31PM +0200, Jan Beulich wrote:
> On 04.10.2022 12:54, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 12:44:16PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 12:38, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 12:23:23PM +0200, Jan Beulich wrote:
> On 0
On Tue, Oct 04, 2022 at 02:21:20PM +0200, Jan Beulich wrote:
> On 04.10.2022 14:17, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 12:40:10PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 11:27, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 11:01:18AM +0200, Jan Beulich wrote:
> On 3
On 04.10.2022 14:52, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 02:18:31PM +0200, Jan Beulich wrote:
>> On 04.10.2022 12:54, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 12:44:16PM +0200, Jan Beulich wrote:
On 04.10.2022 12:38, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 1
On 04.10.2022 14:59, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 02:21:20PM +0200, Jan Beulich wrote:
>> On 04.10.2022 14:17, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 12:40:10PM +0200, Jan Beulich wrote:
On 04.10.2022 11:27, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 1
On Tue, Oct 04, 2022 at 03:15:02PM +0200, Jan Beulich wrote:
> On 04.10.2022 14:59, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 02:21:20PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 14:17, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 12:40:10PM +0200, Jan Beulich wrote:
> On 0
On 04.10.2022 15:55, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 03:15:02PM +0200, Jan Beulich wrote:
>> On 04.10.2022 14:59, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 02:21:20PM +0200, Jan Beulich wrote:
On 04.10.2022 14:17, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 1
On Tue, Oct 04, 2022 at 03:10:57PM +0200, Jan Beulich wrote:
> On 04.10.2022 14:52, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 02:18:31PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 12:54, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 12:44:16PM +0200, Jan Beulich wrote:
> On 0
On 29.08.22 17:15, Jason Andryuk wrote:
An HVM guest with linux stubdom and 2 PCI devices failed to start as
libxl timed out waiting for the PCI devices to be added. It happens
intermittently but with some regularity. libxl wrote the two xenstore
entries for the devices, but then timed out wait
On 04.10.2022 16:01, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 03:10:57PM +0200, Jan Beulich wrote:
>> On 04.10.2022 14:52, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 02:18:31PM +0200, Jan Beulich wrote:
On 04.10.2022 12:54, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 1
On Tue, Oct 04, 2022 at 10:31:25AM +0200, Jan Beulich wrote:
> On 30.09.2022 23:02, Demi Marie Obenour wrote:
> > As discussed on xen-devel, using EfiRuntimeServicesData for more than is
> > absolutely necessary is a bad idea.
> > ---
> > xen/common/efi/boot.c | 19 +++
> > 1 file
On Tue, Oct 04, 2022 at 04:39:26PM +0200, Jan Beulich wrote:
> On 04.10.2022 16:01, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 03:10:57PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 14:52, Roger Pau Monné wrote:
> >>> On Tue, Oct 04, 2022 at 02:18:31PM +0200, Jan Beulich wrote:
> On 0
On 04.10.22 12:58, Jan Beulich wrote:
On 04.10.2022 10:43, Juergen Gross wrote:
Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
of read/write MSR in case the MSR access isn't emulated via Xen. Allow
the caller to select the potentially faulting variant by passing NULL
for
On 04.10.22 13:03, Jan Beulich wrote:
On 04.10.2022 10:43, Juergen Gross wrote:
Refactor and rename xen_read_msr_safe() and xen_write_msr_safe() to
support both cases of MSR accesses, safe ones and potentially GP-fault
generating ones.
This will prepare to no longer swallow GPs silently in xen_
The EFI memory map contains two memory types (EfiMemoryMappedIO and
EfiMemoryMappedIOPortSpace) used to describe IO memory areas used by
EFI firmware.
The current parsing of the EFI memory map is translating
EfiMemoryMappedIO to E820_RESERVED on x86. This causes issues on some
boxes as the firmwa
On 04.10.2022 17:22, Juergen Gross wrote:
> On 04.10.22 12:58, Jan Beulich wrote:
>> On 04.10.2022 10:43, Juergen Gross wrote:
>>> Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
>>> of read/write MSR in case the MSR access isn't emulated via Xen. Allow
>>> the caller to sel
On 04.10.2022 17:20, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 04:39:26PM +0200, Jan Beulich wrote:
>> On 04.10.2022 16:01, Roger Pau Monné wrote:
>>> On Tue, Oct 04, 2022 at 03:10:57PM +0200, Jan Beulich wrote:
On 04.10.2022 14:52, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 0
On 30.09.2022 14:51, Bertrand Marquis wrote:
>> On 30 Sep 2022, at 09:50, Jan Beulich wrote:
>>
>> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>> higher priority than the type of the range. To avoid accessing memory at
>> runtime which was re-used for other purposes, m
flight 173414 linux-linus real [real]
flight 173417 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173414/
http://logs.test-lab.xenproject.org/osstest/logs/173417/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
There is a spelling mistake in the module description. Fix it.
Signed-off-by: Colin Ian King
---
drivers/xen/xen-pciback/xenbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index bde63ef677b8..d171091eec
Hi Dega,
AMD/Xilinx has a FreeRTOS port that works on Xen (at least on Xilinx
boards). The code is public and open source although typically to build
it you'd need the Vitis SDK.
The code itself is available here:
https://github.com/Xilinx/embeddedsw
https://github.com/Xilinx/embeddedsw/tree/mast
A future change will want a cpuid-like identifier which doesn't have a mapping
to a feature bit.
* Pass the feature name into the parse callback.
* Exclude a feature value of ~0u from falling into the general set/clear bit
paths.
* In gen-cpuid.py, insert a placeholder to collect all the pse
Slightly RFC. I'm a little uncertain about putting doitm into cpuid= but it's
the least bad option I can think of.
Andrew Cooper (2):
x86/cpuid: Infrastructure to support pseudo feature identifiers
x86: Activate Data Operand Invariant Timing Mode by default
xen/arch/x86/cpu/common.c
Intel IceLake and later CPUs have microarchitectural behaviours which cause
data-dependent timing behaviour. This is not an issue for 99% of software,
but it is a problem for cryptography routines. On these CPUs, a new
architectural feature, DOITM, was retrofitted in microcode.
For now, Xen can'
On 04.10.2022 17:36, Roger Pau Monne wrote:
> The EFI memory map contains two memory types (EfiMemoryMappedIO and
> EfiMemoryMappedIOPortSpace) used to describe IO memory areas used by
> EFI firmware.
>
> The current parsing of the EFI memory map is translating
> EfiMemoryMappedIO to E820_RESERVED
On 04.10.22 18:06, Colin Ian King wrote:
There is a spelling mistake in the module description. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signat
On Tue, Oct 04, 2022 at 10:22:13AM +0200, Jan Beulich wrote:
> On 01.10.2022 02:30, Demi Marie Obenour wrote:
> > On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote:
> >> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour wrote:
> >>> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheu
On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
> Intel IceLake and later CPUs have microarchitectural behaviours which cause
> data-dependent timing behaviour. This is not an issue for 99% of software,
> but it is a problem for cryptography routines. On these CPUs, a new
> archite
flight 173416 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173416/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173412
test-amd64-i386-xl-qemuu-win7-amd64
On Oct 4, 2022, at 1:22 AM, Alexander Graf wrote:
> ⚠ External Email
>
> Hey Nadav,
>
> On 03.10.22 19:34, Nadav Amit wrote:
>> On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
>>
>>> Not my but rather PCI maintainer's call but IMHO dropping 'const' is
>>> better, introducing a new global
flight 173418 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173418/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 769879e2a6761277b8099014ad8bc426d23dc50b
baseline version:
ovmf 12973359d02d59c0f856b
On 10/4/22 4:43 AM, Juergen Gross wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- if (is_amd_pmu_msr(msr)) {
- if (!xen_amd_pmu_emulate(msr, val, 1))
-
flight 173420 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173420/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f931506815548cee5a3929856bfc98266c3c
baseline version:
ovmf 769879e2a6761277b8099
flight 173419 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173419/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 broken
test-amd64
On 2022-10-03 21:51, Demi Marie Obenour wrote:
On Mon, Oct 03, 2022 at 09:31:25PM -0400, M. Vefa Bicakci wrote:
On 2022-10-02 20:29, Demi Marie Obenour wrote:
On Sun, Oct 02, 2022 at 06:20:05PM -0400, M. Vefa Bicakci wrote:
Prior to this commit, if a grant mapping operation failed partially,
s
On 04.10.2022 17:46, Demi Marie Obenour wrote:
> Linux has a function called efi_mem_reserve() that is used to reserve
> EfiBootServicesData memory that contains e.g. EFI configuration tables.
> This function does not work under Xen because Xen could have already
> clobbered the memory. efi_mem_re
73 matches
Mail list logo
