Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.19-rc1b-tag
xen: 2nd batch for v5.19-rc1
It contains 2 cleanup patches for Xen related code and (more important)
an update of MAINTAINERS for Xen, as Boris Ostrovsky decided to step
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same thing whe
flight 170821 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714
test-amd64-amd64-li
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Currently, memory is added to the boot allocator after the xenheap
> mappings are done. This will break if the first mapping is more than
> 512GB of RAM.
>
> In addition to that, a follow-up patch will rework setup_xenheap_mapping
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() call by map_pages_to_xen() call.
>
> This has the advantage to remove the differences between 32-bit and
> 64-bit code.
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> In a follow-up patch, we will want to populate the boot allocator
> separately for arm64. The code will end up to be very similar to the one
> on arm32. So move out the code in a new helper populate_boot_allocator().
>
> For now t
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() calls by map_pages_to_xen() calls.
>
> The mapping can also be marked read-only as Xen should not modify
> the host Devi
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Now that xen_pt_update_entry() is able to deal with different mapping
> size, we can replace the open-coding of the page-tables update by a call
> to modify_xen_mappings().
>
> As the function is not meant to fail, a BUG_ON() is a
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Currently, the function xen_pt_update() will flush the TLBs even when
> the mappings are inserted. This is a bit wasteful because we don't
> allow mapping replacement. Even if we were, the flush would need to
> happen earlier becau
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, xen_pt_update_entry() only supports mapping at level 3
> (i.e 4KB mapping). While this is fine for most of the runtime helper,
> the boot code will require to use superpage mapping.
>
> We don't want to allow superp
flight 170820 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170820/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170812
test-armhf-armhf-libvirt 16 sav
On Tue, 17 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Add ability to allocate unpopulated DMAable (contiguous) pages
> suitable for grant mapping into. This is going to be used by gnttab
> code (see gnttab_dma_alloc_pages()).
>
> TODO: There is a code duplication in f
On Tue, 17 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Depends on CONFIG_XEN_UNPOPULATED_ALLOC. If enabled then unpopulated
> DMAable (contiguous) pages will be allocated for grant mapping into
> instead of ballooning out real RAM pages.
>
> TODO: Fallback to real RAM
flight 170815 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170815/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714
test-amd64-amd64-li
On Fri, Jun 03, 2022 at 03:34:33PM +0200, Jan Beulich wrote:
> On 21.04.2022 15:21, Roger Pau Monne wrote:
> > Do not allow to write to RTE registers using io_apic_write and instead
> > require changes to RTE to be performed using ioapic_write_entry.
>
> Hmm, this doubles the number of MMIO access
On Fri, Jun 03, 2022 at 03:24:37PM +0200, Jan Beulich wrote:
> On 21.04.2022 15:21, Roger Pau Monne wrote:
> > No functional change intended.
> >
> > Signed-off-by: Roger Pau Monné
>
> Once seeing the purpose (in a later patch, I suppose) I certainly
> don't mind. We do have a couple of literal
On 03.06.22 00:53, Demi Marie Obenour wrote:
unmap_grant_pages() currently waits for the pages to no longer be used.
In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
deadlock against i915: i915 was waiting for gntdev's MMU notifier to
finish, while gntdev was waiting for i91
On Fri, Jun 03, 2022 at 03:19:34PM +0200, Jan Beulich wrote:
> On 21.04.2022 15:21, Roger Pau Monne wrote:
> > Allow disabling (masking) IO-APIC pins set to edge trigger mode. This
> > is required in order to safely migrate such interrupts between CPUs,
> > as the write to update the IO-APIC RTE (
On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
> On 26.05.2022 13:11, Roger Pau Monne wrote:
> > Under certain conditions guests can get the CPU stuck in an unbounded
> > loop without the possibility of an interrupt window to occur on
> > instruction boundary. This was the case with
flight 170819 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170819/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0a4019ec9de64c6565ea545dc8d847afe2b30d6c
baseline version:
ovmf 632574ced10fe184d5665
On Fri, Jun 03, 2022 at 02:16:47PM +0200, Jan Beulich wrote:
> On 26.05.2022 13:11, Roger Pau Monne wrote:
> > Add support for enabling Bus Lock Detection on Intel systems. Such
> > detection works by triggering a vmexit, which ought to be enough of a
> > pause to prevent a guest from abusing of t
On 08.02.2022 19:00, Oleksii Moisieiev wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -512,7 +512,7 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
>
> if ( iommu )
> {
> -if ( config->iommu_opts & ~XEN_DOMCTL_IOMMU_no_sharept
On 21.04.2022 15:21, Roger Pau Monne wrote:
> Do not allow to write to RTE registers using io_apic_write and instead
> require changes to RTE to be performed using ioapic_write_entry.
Hmm, this doubles the number of MMIO access in affected code fragments.
> --- a/xen/arch/x86/include/asm/io_apic.
On 21.04.2022 15:21, Roger Pau Monne wrote:
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Once seeing the purpose (in a later patch, I suppose) I certainly
don't mind. We do have a couple of literal initializers, though (see
e.g. the top of ioapic_guest_write()). Do those s
On 21.04.2022 15:21, Roger Pau Monne wrote:
> Allow disabling (masking) IO-APIC pins set to edge trigger mode. This
> is required in order to safely migrate such interrupts between CPUs,
> as the write to update the IO-APIC RTE (or the IRTE) is not done
> atomically,
For IRTE on VT-d we use cmpxc
On 31.05.2022 04:41, Daniel P. Smith wrote:
> --- a/xen/arch/x86/guest/xen/pvh-boot.c
> +++ b/xen/arch/x86/guest/xen/pvh-boot.c
> @@ -32,7 +32,7 @@ bool __initdata pvh_boot;
> uint32_t __initdata pvh_start_info_pa;
>
> static multiboot_info_t __initdata pvh_mbi;
> -static module_t __initdata pv
On 26.05.2022 13:11, Roger Pau Monne wrote:
> Under certain conditions guests can get the CPU stuck in an unbounded
> loop without the possibility of an interrupt window to occur on
> instruction boundary. This was the case with the scenarios described
> in XSA-156.
>
> Make use of the Notify VM
On 26.05.2022 13:11, Roger Pau Monne wrote:
> Introduce a small helper to OR VMX_INTR_SHADOW_NMI in
> GUEST_INTERRUPTIBILITY_INFO in order to help dealing with the NMI
> unblocked by IRET case. Replace the existing usage in handling
> EXIT_REASON_EXCEPTION_NMI and also add such handling to EPT vio
On 26.05.2022 13:11, Roger Pau Monne wrote:
> Add support for enabling Bus Lock Detection on Intel systems. Such
> detection works by triggering a vmexit, which ought to be enough of a
> pause to prevent a guest from abusing of the Bus Lock.
>
> Add an extra Xen perf counter to track the number o
flight 170818 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170818/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 632574ced10fe184d5665b73c62c959109c39961
baseline version:
ovmf 0223898f3e45e8c7e9d8b
Hello Anthony and thanks for your comments. I addressed them below:
On Tue, May 31, 2022 at 12:16:02PM +0100, Anthony PERARD wrote:
> Hi Matias,
>
> On Tue, May 17, 2022 at 04:33:15PM +0200, Matias Ezequiel Vara Larsen wrote:
> > Add a demostration tool that uses the stats_table resource to
> > q
flight 170813 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170813/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-examine-uefi 6 xen-install fail in 170806 pass in 170813
test-armhf-armhf-xl-rtds 18
flight 170816 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170816/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0223898f3e45e8c7e9d8ba01aea5f95a282f420b
baseline version:
ovmf 64706ef761273ba403f9c
flight 170814 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170814/
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
flight 170812 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170812/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail blocked in
170809
test-amd64-amd64-xl-qemuu-win7-a
35 matches
Mail list logo
