A previous patch tried to get Linux to use the ESRT under Xen if it is
in memory of type EfiRuntimeServicesData. However, this turns out to be
a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory
winds up fragmenting both the EFI page tables and the direct map, and
that EfiACPIR
flight 173487 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462
test-arm64-arm64-xl
On Sun, 9 Oct 2022, Julien Grall wrote:
> Hi Stefano,
>
> On 08/10/2022 01:15, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Remove the extra copy of the GPL license and license copyright headers
> > from CONTRIBUTING and the top-level COPYING.
> >
> > Mention of the LICENSES/
On Mon, 10 Oct 2022, Jan Beulich wrote:
> On 08.10.2022 21:08, Julien Grall wrote:
> > On 06/10/2022 15:11, Jan Beulich wrote:
> >>> ... the space cannot become ordinary RAM, then such a precaution
> >>> wouldn't be necessary. After all hiding EfiACPIReclaimMemory from
> >>> Dom0 just because it ca
+Xen/Linux maintainers
On Mon, 10 Oct 2022, Leo Yan wrote:
> Hi there,
>
> I tested the networking performance on my Arm64 platform in Xen
> virtual machine, below I will try to give out summary for testing
> result and share some analysis, at the end I want to check a bit
> from the community a
> From: Jan Beulich
> Sent: Monday, October 10, 2022 6:25 PM
>
> With the addition of vmx_add_msr() calls to construct_vmcs() there are
> now cases where simply freeing the VMCS isn't enough: The MSR bitmap
> page as well as one of the MSR area ones (if it's the 2nd vmx_add_msr()
> which fails) m
On Mon, 10 Oct 2022, Michal Orzel wrote:
> On 10/10/2022 12:48, Xenia Ragiadakou wrote:
> >
> >
> > On 10/10/22 12:48, Michal Orzel wrote:
> >> Hi Xenia,
> >>
> >> On 10/10/2022 10:52, Xenia Ragiadakou wrote:
> >>>
> >>>
> >>> On 10/10/22 10:29, Michal Orzel wrote:
> >>>
> >>> Hi Michal
> >>>
> >
On 06/10/2022 14:11, Jan Beulich wrote:
> In an entirely different context I came across Linux commit 428e3d08574b
> ("KVM: x86: Fix zero iterations REP-string"), which points out that
> we're still doing things wrong: For one, there's no zero-extension at
> all on AMD. And then while RCX is zero-e
flight 173486 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-arm64-arm64-xl-seattle 8 xen-boot
On 06/10/2022 14:11, Jan Beulich wrote:
> Based on observations on a fair range of hardware from both primary
> vendors even zero-iteration-count instances of these insns perform the
> port related permission checking first.
>
> Fixes: fe300600464c ("x86: Fix emulation of REP prefix")
> Signed-off-
On Tue, Oct 04, 2022 at 06:48:11PM +, Nadav Amit wrote:
> 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 main
On 15/09/2022 08:22, Jan Beulich wrote:
> protmode_load_seg() would better adhere to that "feature" of clearing
> base (and limit) during NULL selector loads.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On Oct 4, 2022, at 11:48 AM, Nadav Amit wrote:
> 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 I
flight 173485 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173485/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f80580f56b267c96f16f985dbf707b2f96947da4
baseline version:
ovmf 8db4e9f9a0c2ec992e282
Hi there,
I tested the networking performance on my Arm64 platform in Xen
virtual machine, below I will try to give out summary for testing
result and share some analysis, at the end I want to check a bit
from the community and get suggestion before I can proceed.
First of all, if you want to kno
flight 173483 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173483/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462
test-arm64-arm64-xl
On 10/10/2022 12:48, Xenia Ragiadakou wrote:
>
>
> On 10/10/22 12:48, Michal Orzel wrote:
>> Hi Xenia,
>>
>> On 10/10/2022 10:52, Xenia Ragiadakou wrote:
>>>
>>>
>>> On 10/10/22 10:29, Michal Orzel wrote:
>>>
>>> Hi Michal
>>>
At the moment, ImageBuilder assumes that all addresses/sizes a
HI Stefano,
> On 8 Oct 2022, at 00:36, Stefano Stabellini wrote:
>
> On Wed, 24 Aug 2022, Bertrand Marquis wrote:
>> This patch series is a first attempt to check if we could use Yocto in
>> gitlab ci to build and run xen on qemu for arm, arm64 and x86.
>>
>> The first patch is making sure buil
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [PATCH][4.17?] VMX: correct error handling in vmx_create_vmcs()
>
> With the addition of vmx_add_msr() calls to construct_vmcs() there are
> now cases where simply freeing the VMCS isn't enough: The MSR bitmap
> page as well as
On 10/10/22 12:48, Michal Orzel wrote:
Hi Xenia,
On 10/10/2022 10:52, Xenia Ragiadakou wrote:
On 10/10/22 10:29, Michal Orzel wrote:
Hi Michal
At the moment, ImageBuilder assumes that all addresses/sizes are
32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
value for t
With the addition of vmx_add_msr() calls to construct_vmcs() there are
now cases where simply freeing the VMCS isn't enough: The MSR bitmap
page as well as one of the MSR area ones (if it's the 2nd vmx_add_msr()
which fails) may also need freeing. Switch to using vmx_destroy_vmcs()
instead.
Fixes:
Hi Xenia,
On 10/10/2022 10:52, Xenia Ragiadakou wrote:
>
>
> On 10/10/22 10:29, Michal Orzel wrote:
>
> Hi Michal
>
>> At the moment, ImageBuilder assumes that all addresses/sizes are
>> 32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
>> value for the first cell. Because o
On 07.10.2022 21:36, Andrew Cooper wrote:
> On 26/08/2021 11:14, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -3289,17 +3292,15 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
>> "status frames, but has only %u\n",
>> d
flight 173484 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173484/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8db4e9f9a0c2ec992e28259ceb7a8eb316716b05
baseline version:
ovmf 3c9e2f239a38590b4e3a8
On 10/10/22 10:29, Michal Orzel wrote:
Hi Michal
At the moment, ImageBuilder assumes that all addresses/sizes are
32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
value for the first cell. Because of that, we cannot specify
MEMORY_START and MEMORY_END to be above 32-bits (
On 08.10.22 17:12, Borislav Petkov wrote:
> Adding Xen and Jailhouse people and MLs to Cc.
>
> Folks, thread starts here:
>
> https://lore.kernel.org/r/1650035401-22855-1-git-send-email-ross.philip...@oracle.com
>
> On Fri, Apr 15, 2022 at 11:10:00AM -0400, Ross Philipson wrote:
>> There are a n
On 07.10.2022 21:57, Andrew Cooper wrote:
> On 26/08/2021 11:15, Jan Beulich wrote:
>> --- a/xen/common/compat/grant_table.c
>> +++ b/xen/common/compat/grant_table.c
>> @@ -175,8 +175,15 @@ int compat_grant_table_op(unsigned int c
>> i < (_s_)->nr_frames; ++i ) \
>
On 10.10.2022 09:03, Wei Chen wrote:
> On 2022/10/9 15:25, Wei Chen wrote:
> Even more so an answer to my question would be nice: You'll then have
> CONFIG_HAS_NUMA_NODE_FWID=y even on Arm (using PXM as mandated by ACPI
> when in ACPI mode). But then what's the FWID for DT? I know it wa
flight 173482 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173482/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-migrupgrade 11 xen-install/dst_host fail in 173466 pass in
173482
test-amd64-i386-qemuu-rhel6h
At the moment, ImageBuilder assumes that all addresses/sizes are
32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
value for the first cell. Because of that, we cannot specify
MEMORY_START and MEMORY_END to be above 32-bits (e.g. to place the images
in the upper memory bank).
Ad
Hi Jan,
On 2022/10/9 15:25, Wei Chen wrote:
Hi Jan,
>
Even more so an answer to my question would be nice: You'll then have
CONFIG_HAS_NUMA_NODE_FWID=y even on Arm (using PXM as mandated by ACPI
when in ACPI mode). But then what's the FWID for DT? I know it was me
to suggest this build time dis
31 matches
Mail list logo
