The size of the video memory of PVH guests should be set to 0 in case
no value has been specified.
Doing not so will leave it to be -1, resulting in an additional 1 kB
of RAM being advertised in the memory map (here the output of a PVH
Mini-OS boot with 16 MB of RAM assigned):
Memory map:
000
flight 167064 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167064/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
REGR. vs. 16
On 02.12.2021 20:16, Andrew Cooper wrote:
> On 02/12/2021 15:28, Jan Beulich wrote:
>> On 02.12.2021 16:12, Roger Pau Monné wrote:
>>> On Wed, Dec 01, 2021 at 12:45:12PM +0100, Jan Beulich wrote:
On 01.12.2021 11:32, Roger Pau Monné wrote:
> On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Be
flight 167023 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166839
test-amd64-amd64-xl-p
flight 167051 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
REGR. vs. 16
On Thu, 2021-12-02 at 20:07 +0100, Christophe JAILLET wrote:
> Le 02/12/2021 à 19:16, Joe Perches a écrit :
> > On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
> > > Le 02/12/2021 à 07:12, Juergen Gross a écrit :
> > > > On 01.12.21 22:10, Christophe JAILLET wrote:
> > > > > Use 'bitma
flight 167007 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 18 guest-start/debian.repeat fail REGR. vs. 166954
test-amd64-amd64-
flight 167019 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166942
test-amd64-coresche
Hi Thomas
On Thu, Dec 02, 2021 at 09:40:08PM +0100, Thomas Gleixner wrote:
> Ashok,
>
> On Thu, Dec 02 2021 at 11:21, Ashok Raj wrote:
> > On Thu, Dec 02, 2021 at 11:16:39AM +0100, Thomas Gleixner wrote:
> >> On Wed, Dec 01 2021 at 17:08, Megha Dey wrote:
> >> You're missing the real world use ca
flight 167033 xen-unstable-smoke real [real]
flight 167046 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167033/
http://logs.test-lab.xenproject.org/osstest/logs/167046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 166999 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 22 guest-start/debian.repeat fail REGR. vs. 166912
test-amd64-i386-li
Ashok,
On Thu, Dec 02 2021 at 11:21, Ashok Raj wrote:
> On Thu, Dec 02, 2021 at 11:16:39AM +0100, Thomas Gleixner wrote:
>> On Wed, Dec 01 2021 at 17:08, Megha Dey wrote:
>> You're missing the real world use case. The above is fiction.
>
> I don't think there is a valid use case for freeing specif
Hi everyone,
Our next meeting is on Tuesday, December 7th at 1500 UTC.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/0uM9VB27hQfkyZ+A8libTu4E/ Please add
or edit any items to this agenda. Alternatively, please feel free to email
me directly with agenda items.
Please put your nam
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some
open-coded arithmetic in allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Use 'bitmap_copy()' to avoid an explicit 'memcpy()'
Signed-off-by: Christophe JAILLET
---
v
Hi Thomas,
On Thu, Dec 02, 2021 at 11:16:39AM +0100, Thomas Gleixner wrote:
> Megha,
>
> On Wed, Dec 01 2021 at 17:08, Megha Dey wrote:
> > On 11/26/2021 5:25 PM, Thomas Gleixner wrote:
> >> /**
> >> + * pci_msix_expand_vectors_at - Expand MSI-X interrupts for a device
> >> + *
> >> + * @dev:
On 02/12/2021 15:28, Jan Beulich wrote:
> On 02.12.2021 16:12, Roger Pau Monné wrote:
>> On Wed, Dec 01, 2021 at 12:45:12PM +0100, Jan Beulich wrote:
>>> On 01.12.2021 11:32, Roger Pau Monné wrote:
On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Beulich wrote:
> On 01.12.2021 10:09, Roger Pa
At 12:01 +0100 on 01 Dec (1638360084), Jan Beulich wrote:
> Replace all comparisons against p2m_populate_on_demand (outside of
> switch() statements) with the designated predicate.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
At 11:35 +0100 on 01 Dec (1638358515), Jan Beulich wrote:
> paging_mfn_is_dirty() is moderately expensive, so avoid its use unless
> its result might actually change anything. This means moving the
> surrounding if() down below all other checks that can result in clearing
> _PAGE_RW from sflags, in
Le 02/12/2021 à 19:16, Joe Perches a écrit :
On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
Le 02/12/2021 à 07:12, Juergen Gross a écrit :
On 01.12.21 22:10, Christophe JAILLET wrote:
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid
some open-coded arithmeti
flight 167020 xen-unstable-smoke real [real]
flight 167031 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167020/
http://logs.test-lab.xenproject.org/osstest/logs/167031/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
> Le 02/12/2021 à 07:12, Juergen Gross a écrit :
> > On 01.12.21 22:10, Christophe JAILLET wrote:
> > > Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid
> > > some open-coded arithmetic in allocator arguments.
> > >
Le 02/12/2021 à 07:12, Juergen Gross a écrit :
On 01.12.21 22:10, Christophe JAILLET wrote:
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid
some
open-coded arithmetic in allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency
flight 166997 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166997/
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
On Fri, Sep 24, 2021 at 11:48:57AM +0200, Jan Beulich wrote:
> I think this flush was overlooked when flushing was moved out of the
> core (un)mapping functions. The flush the caller is required to invoke
> anyway will satisfy the needs resulting from the splitting of a
> superpage.
>
> Signed-off
On 02.12.21 11:09, Julien Grall wrote:
Hi Julien, Jan
Hi Jan,
On 13/09/2021 07:41, Jan Beulich wrote:
Without holding appropriate locks, attempting to remove a prior mapping
of the underlying page is pointless, as the same (or another) mapping
could be re-established by a parallel request o
On 02.12.2021 17:03, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:48:21AM +0200, Jan Beulich wrote:
>> For vendor specific code to support superpages we need to be able to
>> deal with a superpage mapping replacing an intermediate page table (or
>> hierarchy thereof). Consequently an iommu_a
On Fri, Sep 24, 2021 at 11:48:21AM +0200, Jan Beulich wrote:
> For vendor specific code to support superpages we need to be able to
> deal with a superpage mapping replacing an intermediate page table (or
> hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
> needed to free in
On 30.11.2021 16:24, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:45:57AM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -260,12 +260,38 @@ void iommu_domain_destroy(struct domain
>> arch_iommu_domain_destroy(d);
>> }
>
On Thu, Dec 02, 2021 at 03:49:08PM +, Richard W.M. Jones wrote:
>
> Not sure if this is related, but builds are failing with:
>
> FAILED: libblockdev.fa.p/block_export_fuse.c.o
> cc -m64 -mcx16 -Ilibblockdev.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader
> -I/usr/include/fuse3 -I/usr/include
Not sure if this is related, but builds are failing with:
FAILED: libblockdev.fa.p/block_export_fuse.c.o
cc -m64 -mcx16 -Ilibblockdev.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader
-I/usr/include/fuse3 -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/includ
The difference between ->handle_output() and ->handle_aio_output() was
that ->handle_aio_output() returned a bool return value indicating
progress. This was needed by the old polling API but now that the bool
return value is gone, the two functions can be unified.
Signed-off-by: Stefan Hajnoczi
-
Now that virtio-blk and virtio-scsi are ready, get rid of
the handle_aio_output() callback. It's no longer needed.
Signed-off-by: Stefan Hajnoczi
---
include/hw/virtio/virtio.h | 4 +--
hw/block/dataplane/virtio-blk.c | 16 ++
hw/scsi/virtio-scsi-dataplane.c | 54 --
Prepare virtio_scsi_handle_cmd() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi
---
hw/scsi/virtio-scsi.c | 2 +-
1 file changed, 1 inse
The return value of virtio_blk_handle_vq() is no longer used. Get rid of
it. This is a step towards unifying the dataplane and non-dataplane
virtqueue handler functions.
Prepare virtio_blk_handle_output() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd
The virtqueue host notifier API
virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new
buffers. AioContext previously required a bool progress return value
indicating whether an event was handled or not. This is no longer
necessary because the AioContext polling API has been split
Adaptive polling measures the execution time of the polling check plus
handlers called when a polled event becomes ready. Handlers can take a
significant amount of time, making it look like polling was running for
a long time when in fact the event handler was running for a long time.
For example,
v2:
- Cleaned up unused return values in nvme and virtio-blk [Stefano]
- Documented try_poll_mode() ready_list argument [Stefano]
- Unified virtio-blk/scsi dataplane and non-dataplane virtqueue handlers
[Stefano]
The first patch improves AioContext's adaptive polling execution time
measurement. T
On 02.12.2021 16:12, Roger Pau Monné wrote:
> On Wed, Dec 01, 2021 at 12:45:12PM +0100, Jan Beulich wrote:
>> On 01.12.2021 11:32, Roger Pau Monné wrote:
>>> On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Beulich wrote:
On 01.12.2021 10:09, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 1
Hi Luca,
> On 2 Dec 2021, at 15:05, Luca Fancellu wrote:
>
> The example in section "UEFI boot and dom0less on ARM" has
> a wrong compatible for the DTB passthrough, it is "ramdisk"
> instead of "device-tree".
> This patch fixes the example.
>
> Fixes: a1743fc3a9 ("arm/efi: Use dom0less configu
Correction:
I wrote:
> Xen 4.16, the product of 9 months' work by the Xen Project community,
> is now released.
>
> You can find it here:
> git clone -b RELEASE-4.16.0 https://xenbits.xen.org/git-http/xen.git
> https://downloads.xenproject.org/release/xen/4.16.0/
> For more information see th
On Wed, Dec 01, 2021 at 12:45:12PM +0100, Jan Beulich wrote:
> On 01.12.2021 11:32, Roger Pau Monné wrote:
> > On Wed, Dec 01, 2021 at 10:27:21AM +0100, Jan Beulich wrote:
> >> On 01.12.2021 10:09, Roger Pau Monné wrote:
> >>> On Fri, Sep 24, 2021 at 11:46:57AM +0200, Jan Beulich wrote:
> @@ -
The example in section "UEFI boot and dom0less on ARM" has
a wrong compatible for the DTB passthrough, it is "ramdisk"
instead of "device-tree".
This patch fixes the example.
Fixes: a1743fc3a9 ("arm/efi: Use dom0less configuration when using EFI boot")
Signed-off-by: Luca Fancellu
---
Question: D
On 12/1/21 10:02 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary (E.G 39 bit
address line) reported by Hyper-V CPUID ISOLATION_CONFIG. The access
physical address will be original
On Wed, Dec 01, 2021 at 11:02:54AM -0500, Tianyu Lan wrote:
[...]
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 46df59aeaa06..30fd0600b008 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -4,6 +4,7 @@
>
> #include
Xen 4.16, the product of 9 months' work by the Xen Project community,
is now released.
You can find it here:
git clone -b RELEASE-4.16.0 https://xenbits.xen.org/git-http/xen.git
https://downloads.xenproject.org/release/xen/4.16.0/
For more information see the release notes:
https://wiki.xenp
On Wed, Dec 01, 2021 at 11:02:53AM -0500, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides Isolation VM which has memory encrypt support. Add
> hyperv_cc_platform_has() and return true for check of GUEST_MEM_ENCRYPT
> attribute.
>
> Signed-off-by: Tianyu Lan
> ---
> arch/x86/kernel/cc
On Sat, Nov 27, 2021 at 02:18:51AM +0100, Thomas Gleixner wrote:
> No point in looking up things over and over. Just look up the associated
> irq data and work from there.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Wei Liu
On Fri, Sep 24, 2021 at 11:47:41AM +0200, Jan Beulich wrote:
> For large page mappings to be easily usable (i.e. in particular without
> un-shattering of smaller page mappings) and for mapping operations to
> then also be more efficient, pass batches of Dom0 memory to iommu_map().
> In dom0_constru
On 02/12/2021 11:56, Jan Beulich wrote:
> On 30.11.2021 11:04, Andrew Cooper wrote:
>> The calculation in __start_xen() for xen_virt_end is an opencoding of
>> ROUNDUP(_end, 2M). This is __2M_rwdata_end as provided by the linker script.
>>
>> This corrects the bound calculations in arch_livepatch_
On 02/12/2021 11:49, Jan Beulich wrote:
> On 30.11.2021 11:04, Andrew Cooper wrote:
>> multiboot_ptr should be in __initdata - it is only used on the BSP path.
>> Furthermore, the .align 8 then .long means that stack_start is misaligned.
>>
>> Move both into setup.c, which lets the compiler handle
On 25.11.2021 14:39, Anthony PERARD wrote:
> We are going to need the variable XEN_BUILD_EFI earlier.
>
> But a side effect of calculating the value of $(XEN_BUILD_EFI) is to
> also to generate "efi/check.o" which is used for further checks.
> Thus the whole chain that check for EFI support is mov
On 25.11.2021 14:39, Anthony PERARD wrote:
> This will avoid regenerating "compile.h" if the content hasn't changed.
>
> As it's currently the case, the file isn't regenerated during `sudo
> make install` if it exist and does belong to a different user, thus we
> can remove the target "delete-unfr
flight 166990 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166839
test-amd64-amd64-xl-p
On 25.11.2021 14:39, Anthony PERARD wrote:
> This avoid the need to create the symbolic link "include/asm".
>
> Whenever a comment refer to an "asm" headers, this patch avoid
> spelling the arch when not needed to avoid some code churn.
>
> One unrelated change is to sort entries in MAINTAINERS f
On 29.11.2021 13:59, Anton Belousov wrote:
> ---
> tools/firmware/hvmloader/smbios.c | 146
> tools/firmware/hvmloader/smbios_types.h | 76
> 2 files changed, 222 insertions(+)
In addition to what Roger said: Without a commit message it's also unclear
On 30.11.2021 11:04, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
>
> RFC. I don't know if this is something we'd want to keep or not.
>
> Getting extable handling working for test_nx_data is proving tricky, and while
> I can
On 30.11.2021 11:04, Andrew Cooper wrote:
> For security hardening reasons, it advantageous to make setup-once data
> immutable after boot. Borrow __ro_after_init from Linux.
>
> On x86, place .data.ro_after_init at the start of .rodata, excluding it from
> the early permission restrictions. Re-
flight 166980 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166942
test-arm64-arm64-xl
flight 167004 xen-unstable-smoke real [real]
flight 167015 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167004/
http://logs.test-lab.xenproject.org/osstest/logs/167015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On 30.11.2021 11:04, Andrew Cooper wrote:
> At the moment, we have two locations selecting restricted permissions, not
> very far apart on boot, dependent on opposite answers from using_2M_mapping().
> The later location however can shatter superpages if needed, while the former
> cannot.
>
> Coll
On 30.11.2021 11:04, Andrew Cooper wrote:
> The calculation in __start_xen() for xen_virt_end is an opencoding of
> ROUNDUP(_end, 2M). This is __2M_rwdata_end as provided by the linker script.
>
> This corrects the bound calculations in arch_livepatch_init() and
> update_xen_mappings() to not enf
On 30.11.2021 11:04, Andrew Cooper wrote:
> multiboot_ptr should be in __initdata - it is only used on the BSP path.
> Furthermore, the .align 8 then .long means that stack_start is misaligned.
>
> Move both into setup.c, which lets the compiler handle the details correctly,
> as well as providlin
On 30.11.2021 11:04, Andrew Cooper wrote:
> The first loop relocates all reachable non-leaf entries in idle_pg_table[],
> which includes l2_xenmap[511]'s reference to l1_fixmap_x[].
>
> The second loop relocates only leaf mappings in l2_xenmap[], so update the
> skip condition to be opposite to th
On 26.11.21 13:33, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
Acked-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
On 02.12.2021 11:44, Dario Faggioli wrote:
> Hey! So, I noticed this osstests report and got curious about one
> thing, which looks weird to me... If I am missing something obvious,
> sorry for the noise.
>
> On Wed, 2021-12-01 at 05:43 +, osstest service owner wrote:
>> test-armhf-armhf-xl-m
Hi Jan,
On 02/12/2021 10:12, Jan Beulich wrote:
On 02.12.2021 10:09, Julien Grall wrote:
Hi Jan,
On 13/09/2021 07:41, Jan Beulich wrote:
Without holding appropriate locks, attempting to remove a prior mapping
of the underlying page is pointless, as the same (or another) mapping
could be re-es
Hey! So, I noticed this osstests report and got curious about one
thing, which looks weird to me... If I am missing something obvious,
sorry for the noise.
On Wed, 2021-12-01 at 05:43 +, osstest service owner wrote:
> test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail REGR.
> vs.
> On 1 Dec 2021, at 11:15, Andrew Cooper wrote:
>
> Andrew Cooper (2):
> xsm: Switch xsm_ops to __alt_call_maybe_initdata
> xsm: Drop extern of non-existent variable
Reviewed-by: Bertrand Marquis
On Mon, 2021-11-29 at 15:44 +0100, Jan Beulich wrote:
> On 26.11.2021 13:33, Andrew Cooper wrote:
> >
> > Andrew Cooper (63):
> > x86: Introduce support for CET-IBT
> > x86/hypercall: Annotate fnptr targets
> > xen: Annotate fnptr targets from custom_param()
> > xen: Annotate fnptr targets
Megha,
On Wed, Dec 01 2021 at 17:08, Megha Dey wrote:
> On 11/26/2021 5:25 PM, Thomas Gleixner wrote:
>> /**
>> + * pci_msix_expand_vectors_at - Expand MSI-X interrupts for a device
>> + *
>> + * @dev:PCI device to operate on
>> + * @at: Allocate at MSI-X index. If @at == PCI_MSI
On 02.12.2021 10:09, Julien Grall wrote:
> Hi Jan,
>
> On 13/09/2021 07:41, Jan Beulich wrote:
>> Without holding appropriate locks, attempting to remove a prior mapping
>> of the underlying page is pointless, as the same (or another) mapping
>> could be re-established by a parallel request on ano
On 01.12.2021 13:44, Andrew Cooper wrote:
> On 01/12/2021 10:54, Jan Beulich wrote:
>> @@ -2237,11 +2243,11 @@ bool p2m_altp2m_get_or_propagate(struct
>> * to the start of the superpage. NB that we repupose `amfn`
>> * here.
>> */
>> -mask = ~((1UL << page_order) - 1);
>> +
On 01.12.2021 13:01, Andrew Cooper wrote:
> On 01/12/2021 10:53, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -58,14 +58,10 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>unsigned int order)
>> {
>> unsigned long i;
>> -
flight 166978 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 18 guest-start/debian.repeat fail REGR. vs. 166954
test-arm64-arm64-
On 01.12.2021 15:39, Andrew Cooper wrote:
> On 01/12/2021 09:40, Jan Beulich wrote:
>> The actual function should always have lived in core x86 code; move it
>> there, replacing get_cache_line_size() by readily available (except very
>> early during boot; see the code comment) data.
>>
>> Drop the
Hi Jan,
On 13/09/2021 07:41, Jan Beulich wrote:
Without holding appropriate locks, attempting to remove a prior mapping
of the underlying page is pointless, as the same (or another) mapping
could be re-established by a parallel request on another vCPU. Move the
code to Arm's gnttab_set_frame_gfn
Hi Andrew,
On 01/12/2021 21:38, Andrew Cooper wrote:
On 01/12/2021 09:56, Julien Grall wrote:
Hi,
On 01/12/2021 09:38, Jan Beulich wrote:
On 01.12.2021 10:33, Julien Grall wrote:
On 30/11/2021 18:12, Ayan Kumar Halder wrote:
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -
On 01.12.2021 14:02, Andrew Cooper wrote:
> On 01/12/2021 09:41, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -591,7 +591,8 @@ static int __must_check iommu_flush_all(
>> bool_t flush_dev_iotlb;
>> int rc = 0;
>>
>> -
On 01.12.2021 17:06, Andrew Cooper wrote:
> On 01/12/2021 10:35, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/mm-locks.h
>> +++ b/xen/arch/x86/mm/mm-locks.h
>> @@ -40,7 +40,7 @@ static inline void mm_lock_init(mm_lock_
>> l->unlock_level = 0;
>> }
>>
>> -static inline int mm_locked_by_me(mm_
On 01.12.2021 19:33, Andrew Cooper wrote:
> On 01/12/2021 10:35, Jan Beulich wrote:
>> paging_mfn_is_dirty() is moderately expensive, so avoid its use unless
>> its result might actually change anything. This means moving the
>> surrounding if() down below all other checks that can result in cleari
On 01.12.2021 21:13, Andrew Cooper wrote:
> On 01/12/2021 09:14, Jan Beulich wrote:
>> On 30.11.2021 19:11, Andrew Cooper wrote:
>>> Most functions in this call chain have 8 parameters, meaning that the final
>>> two booleans are spilled to the stack for for calls.
>>>
>>> First, delete nestedhap_w
On 01.12.2021 20:07, Andrew Cooper wrote:
> On 01/12/2021 08:20, Jan Beulich wrote:
>> On 26.11.2021 22:22, Andrew Cooper wrote:
>>> With altcall, we convert indirect branches into direct ones. With that
>>> complete, none of the potential targets need an endbr64 instruction.
>> Assuming that no o
82 matches
Mail list logo
