Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration

On 08.04.22 20:21, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for configuring and assisting virtio-mmio based virtio-disk backend (emualator) which is intended to run out of Qemu and could be run in any domain. Although the Virtio block device is quite

Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen

On 24.04.22 18:53, Oleksandr wrote: On 23.04.22 19:40, Christoph Hellwig wrote: Hello Christoph Please split this into one patch that creates grant-dma-ops, and another that sets up the virtio restricted access helpers. Sounds reasonable, will do: 1. grant-dma-ops.c with config XEN_GRANT

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On 22.04.2022 16:07, Tamas K Lengyel wrote: > On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel > wrote: >> >> Allow specify distinct parts of the fork VM to be reset. This is useful when >> a >> fuzzing operation involves mapping in only a handful of pages that are known >> ahead of time. Throwin

osstest: noceras back into production

Hello, The noceras seem to be in working condition again after plugging the hard disks directly into the built in motherboard controller instead of using the external LSI RAID card: http://logs.test-lab.xenproject.org/osstest/logs/169619/ I will bless those now for real test usage. Roger.

Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen

On 24.04.22 20:08, Boris Ostrovsky wrote: On 4/24/22 12:53 PM, Oleksandr wrote: On 23.04.22 19:40, Christoph Hellwig wrote: + +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS +int arch_has_restricted_virtio_memory_access(void) +{ +    return (xen_has_restricted_virtio_memory_acce

Re: [PATCH v3] page_alloc: assert IRQs are enabled in heap alloc/free

On 24.04.2022 17:52, Julien Grall wrote: >> Changes in v3: >> - Use num_online_cpus() in assert. With this ... >> --- a/xen/common/page_alloc.c >> +++ b/xen/common/page_alloc.c >> @@ -162,6 +162,13 @@ >> static char __initdata opt_badpage[100] = ""; >> string_param("badpage", opt_badpage); >>

Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen

On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote: > > Would the Xen specific bits fit into Confidential Computing Platform > > checks? I will let Juergen/Boris comment on this. > > I don't think cc_platform_has would be correct here. Xen certainly > provides more isolation between gue

Re: [PATCH v2 5/6] xen/arm: unpopulate memory when domain is static

On 25.04.2022 08:34, Penny Zheng wrote: >> -Original Message- >> From: Jan Beulich >> Sent: Tuesday, April 19, 2022 5:11 PM >> >> On 18.04.2022 14:22, Penny Zheng wrote: >>> --- a/xen/arch/arm/include/asm/mm.h >>> +++ b/xen/arch/arm/include/asm/mm.h >>> @@ -358,6 +358,23 @@ void clear_and_

Re: [PATCH] xen/mm: page_alloc fix duplicated order shift operation in the loop

On 23.04.2022 21:35, Paran Lee wrote: > It doesn't seem necessary to do that > duplicate calculation of order shift 2^@order in the loop. Once again I'm not convinced. As in the other patch the compiler could do this transformation via its CSE pass if it sees fit. Also (applicable as well to the

RE: [PATCH v2 5/6] xen/arm: unpopulate memory when domain is static

Hi, jan > -Original Message- > From: Jan Beulich > Sent: Monday, April 25, 2022 4:01 PM > To: Penny Zheng > Cc: Wei Chen ; Stefano Stabellini > ; Julien Grall ; Bertrand Marquis > ; Volodymyr Babchuk > ; Andrew Cooper > ; George Dunlap ; > Wei Liu ; xen-devel@lists.xenproject.org > Subje

[PATCH v4 00/21] IOMMU: superpage support when not sharing pagetables

For a long time we've been rather inefficient with IOMMU page table management when not sharing page tables, i.e. in particular for PV (and further specifically also for PV Dom0) and AMD (where nowadays we never share page tables). While up to about 2.5 years ago AMD code had logic to un-shatter pa

[PATCH v4 01/21] AMD/IOMMU: correct potentially-UB shifts

Recent changes (likely 5fafa6cf529a ["AMD/IOMMU: have callers specify the target level for page table walks"]) have made Coverity notice a shift count in iommu_pde_from_dfn() which might in theory grow too large. While this isn't a problem in practice, address the concern nevertheless to not leave

[PATCH v4 02/21] IOMMU: simplify unmap-on-error in iommu_map()

As of 68a8aa5d7264 ("iommu: make map and unmap take a page count, similar to flush") there's no need anymore to have a loop here. Suggested-by: Roger Pau Monné Signed-off-by: Jan Beulich --- v3: New. --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -308,11 +308,9 @

[PATCH v4 03/21] IOMMU: add order parameter to ->{,un}map_page() hooks

Or really, in the case of ->map_page(), accommodate it in the existing "flags" parameter. All call sites will pass 0 for now. Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian Reviewed-by: Roger Pau Monné Acked-by: Julien Grall # Arm --- v4: Re-base. v3: Re-base over new earlier patch. v2: Re

[PATCH v4 04/21] IOMMU: have iommu_{,un}map() split requests into largest possible chunks

Introduce a helper function to determine the largest possible mapping that allows covering a request (or the next part of it that is left to be processed). In order to not add yet more recurring dfn_add() / mfn_add() to the two callers of the new helper, also introduce local variables holding the

[PATCH v4 05/21] IOMMU/x86: restrict IO-APIC mappings for PV Dom0

While already the case for PVH, there's no reason to treat PV differently here, though of course the addresses get taken from another source in this case. Except that, to match CPU side mappings, by default we permit r/o ones. This then also means we now deal consistently with IO-APICs whose MMIO i

[PATCH v4 06/21] IOMMU/x86: perform PV Dom0 mappings in batches

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_construct_pv() and its helpers (covering strict mode) this additionally requ

[PATCH v4 08/21] AMD/IOMMU: walk trees upon page fault

This is to aid diagnosing issues and largely matches VT-d's behavior. Since I'm adding permissions output here as well, take the opportunity and also add their displaying to amd_dump_page_table_level(). Signed-off-by: Jan Beulich --- Note: "largely matches VT-d's behavior" includes the lack of an

[PATCH v4 09/21] AMD/IOMMU: return old PTE from {set,clear}_iommu_pte_present()

In order to free intermediate page tables when replacing smaller mappings by a single larger one callers will need to know the full PTE. Flush indicators can be derived from this in the callers (and outside the locked regions). First split set_iommu_pte_present() from set_iommu_ptes_present(): Only

[PATCH v4 10/21] AMD/IOMMU: allow use of superpage mappings

No separate feature flags exist which would control availability of these; the only restriction is HATS (establishing the maximum number of page table levels in general), and even that has a lower bound of 4. Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via non-default page size

[PATCH v4 11/21] VT-d: allow use of superpage mappings

... depending on feature availability (and absence of quirks). Also make the page table dumping function aware of superpages. Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian --- v4: Change type of queue_free_pt()'s 1st parameter. Re-base. v3: Rename queue_free_pt()'s last parameter. Replace

[PATCH v4 12/21] IOMMU: fold flush-all hook into "flush one"

Having a separate flush-all hook has always been puzzling me some. We will want to be able to force a full flush via accumulated flush flags from the map/unmap functions. Introduce a respective new flag and fold all flush handling to use the single remaining hook. Note that because of the respecti

[PATCH v4 13/21] IOMMU/x86: prefill newly allocate page tables

Page tables are used for two purposes after allocation: They either start out all empty, or they get filled to replace a superpage. Subsequently, to replace all empty or fully contiguous page tables, contiguous sub-regions will be recorded within individual page tables. Install the initial set of m

[PATCH v4 14/21] x86: introduce helper for recording degree of contiguity in page tables

This is a re-usable helper (kind of a template) which gets introduced without users so that the individual subsequent patches introducing such users can get committed independently of one another. See the comment at the top of the new file. To demonstrate the effect, if a page table had just 16 en

[PATCH v4 07/21] IOMMU/x86: support freeing of pagetables

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 individual page tables while a domain is still alive. Since the freeing

[PATCH v4 16/21] VT-d: free all-empty page tables

When a page table ends up with no present entries left, it can be replaced by a non-present entry at the next higher level. The page table itself can then be scheduled for freeing. Note that while its output isn't used there yet, pt_update_contig_markers() right away needs to be called in all plac

[PATCH v4 17/21] AMD/IOMMU: replace all-contiguous page tables by superpage mappings

When a page table ends up with all contiguous entries (including all identical attributes), it can be replaced by a superpage entry at the next higher level. The page table itself can then be scheduled for freeing. Signed-off-by: Jan Beulich --- Unlike the freeing of all-empty page tables, this c

[PATCH v4 18/21] VT-d: replace all-contiguous page tables by superpage mappings

When a page table ends up with all contiguous entries (including all identical attributes), it can be replaced by a superpage entry at the next higher level. The page table itself can then be scheduled for freeing. The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap for whenever

[PATCH v4 20/21] VT-d: fold iommu_flush_iotlb{,_pages}()

With iommu_flush_iotlb_all() gone, iommu_flush_iotlb_pages() is merely a wrapper around the not otherwise called iommu_flush_iotlb(). Fold both functions. No functional change intended. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrou

[PATCH v4 21/21] VT-d: fold dma_pte_clear_one() into its only caller

This way intel_iommu_unmap_page() ends up quite a bit more similar to intel_iommu_map_page(). No functional change intended. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -806,75 +806,6 @@ static void queue_free_pt

[PATCH v2] x86+libxl: correct p2m (shadow) memory pool size calculation

The reference "to shadow the resident processes" is applicable to domains (potentially) running in shadow mode only. Adjust the calculations accordingly. This, however, requires further parameters. Since the original function is deprecated anyway, and since it can't be changed (for being part of a

[PATCH v4 15/21] AMD/IOMMU: free all-empty page tables

When a page table ends up with no present entries left, it can be replaced by a non-present entry at the next higher level. The page table itself can then be scheduled for freeing. Note that while its output isn't used there yet, pt_update_contig_markers() right away needs to be called in all plac

[PATCH v4 19/21] IOMMU/x86: add perf counters for page table splitting / coalescing

Signed-off-by: Jan Beulich Reviewed-by: Kevin tian --- v3: New. --- a/xen/arch/x86/include/asm/perfc_defn.h +++ b/xen/arch/x86/include/asm/perfc_defn.h @@ -125,4 +125,7 @@ PERFCOUNTER(realmode_exits, "vmexit PERFCOUNTER(pauseloop_exits, "vmexits from Pause-Loop Detection") +PERFCOUNTER

[ovmf test] 169700: regressions - FAIL

flight 169700 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169700/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen

On 25.04.22 09:58, Christoph Hellwig wrote: On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote: Would the Xen specific bits fit into Confidential Computing Platform checks? I will let Juergen/Boris comment on this. I don't think cc_platform_has would be correct here. Xen certainly p

[xen-unstable test] 169694: tolerable FAIL

flight 169694 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169694/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169666 test-amd64-amd64-qemuu-nested-amd 20

Re: [PATCH v3 1/2] xsm: create idle domain privileged and demote after setup

On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote: > There are now instances where internal hypervisor logic needs to make resource > allocation calls that are protected by XSM checks. The internal hypervisor > logic > is represented a number of system domains which by designed are r

[PATCH v2] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash

When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL pointer. One of several bugs here is known-but-compiled-out subops falling into the default chain and hitting unrelated logic. Remove the CONFIG_GDBSX ifdefary in arch_do_domctl() by implementing gdbsx_domctl() and moving the

[ovmf test] 169701: regressions - FAIL

flight 169701 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169701/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

[linux-linus test] 169696: tolerable FAIL - PUSHED

flight 169696 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/169696/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 169686 Tests which did not succeed,

[libvirt test] 169699: regressions - FAIL

flight 169699 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169699/ 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

[ovmf test] 169702: regressions - FAIL

flight 169702 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169702/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

[PATCH RFC] EFI: strip xen.efi when putting it on the EFI partition

With debug info retained, xen.efi can be quite large. Unlike for xen.gz there's no intermediate step (mkelf32 there) involved which would strip debug info kind of as a side effect. While the installing of xen.efi on the EFI partition is an optional step (intended to be a courtesy to the developer),

[PATCH] EFI: don't mistakenly delete a file we never installed

Just like for "install", make dealing with xen.efi on the EFI partition dependent upon mount point and vendor directory being known. Signed-off-by: Jan Beulich --- a/xen/Makefile +++ b/xen/Makefile @@ -515,7 +515,9 @@ _uninstall: rm -f $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map

Re: [PATCH v3 1/2] xsm: create idle domain privileged and demote after setup

On 25.04.2022 11:44, Roger Pau Monné wrote: > On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote: >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -621,6 +621,9 @@ static void noreturn init_done(void) >> void *va; >> unsigned long start, end; >> >> +if

Re: [EXT] Re: DOMU: Virtual Function FLR in PCI passthrough is crashing

Hi Jan Beulich, Thank you very much. Please see my inline comments below. From: Jan Beulich Sent: 20 April 2022 18:37 To: Naresh Bhat Cc: jul...@xen.org ; sstabell...@kernel.org ; xen-devel@lists.xenproject.org Subject: [EXT] Re: DOMU: Virtual Function FLR in PCI passthrough is crashing  

Re: [PATCH v2] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash

On 25.04.2022 12:06, Andrew Cooper wrote: > @@ -178,6 +179,71 @@ void domain_pause_for_debugger(void) > send_global_virq(VIRQ_DEBUGGER); > } > > +long gdbsx_domctl(struct domain *d, struct xen_domctl *domctl, bool > *copyback) Is there anything that requires "long" (and not just "int"

Re: [EXT] Re: DOMU: Virtual Function FLR in PCI passthrough is crashing

On 25.04.2022 13:01, Naresh Bhat wrote: > From: Jan Beulich > Sent: 20 April 2022 18:37 > > On 20.04.2022 14:48, Naresh Bhat wrote: >> I have the following setup and try to test the Function Level Reset feature.  >> Any suggestions or pointers will be very much helpful. >> >> DOM0 >> Distributio

Re: [PATCH v3 0/3] amd/msr: implement MSR_VIRT_SPEC_CTRL for HVM guests

On Fri, Apr 22, 2022 at 06:49:57PM +, Andrew Cooper wrote: > On 31/03/2022 10:27, Roger Pau Monne wrote: > > Hello, > > > > The following series implements support for MSR_VIRT_SPEC_CTRL > > (VIRT_SSBD) on different AMD CPU families. > > > > Note that the support is added backwards, starting wi

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Mon, Apr 25, 2022, 3:49 AM Jan Beulich wrote: > On 22.04.2022 16:07, Tamas K Lengyel wrote: > > On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel > wrote: > >> > >> Allow specify distinct parts of the fork VM to be reset. This is useful > when a > >> fuzzing operation involves mapping in only a

[ovmf test] 169703: regressions - FAIL

flight 169703 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169703/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH v3 1/2] xsm: create idle domain privileged and demote after setup

On Mon, Apr 25, 2022 at 12:53:02PM +0200, Jan Beulich wrote: > On 25.04.2022 11:44, Roger Pau Monné wrote: > > On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote: > >> --- a/xen/arch/x86/setup.c > >> +++ b/xen/arch/x86/setup.c > >> @@ -621,6 +621,9 @@ static void noreturn init_done(voi

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On 25.04.2022 13:29, Tamas K Lengyel wrote: > On Mon, Apr 25, 2022, 3:49 AM Jan Beulich wrote: > >> On 22.04.2022 16:07, Tamas K Lengyel wrote: >>> On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel >> wrote: Allow specify distinct parts of the fork VM to be reset. This is useful >> when

[ovmf test] 169704: regressions - FAIL

flight 169704 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169704/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration

On 25.04.22 10:43, Juergen Gross wrote: Hello Juergen Thank you for the feedback. On 08.04.22 20:21, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for configuring and assisting virtio-mmio based virtio-disk backend (emualator) which is intended to

Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration

On 25.04.22 14:02, Oleksandr wrote: On 25.04.22 10:43, Juergen Gross wrote: Hello Juergen Thank you for the feedback. On 08.04.22 20:21, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for configuring and assisting virtio-mmio based virtio-disk backe

Re: [PATCH v2] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash

On 25/04/2022 12:04, Jan Beulich wrote: > On 25.04.2022 12:06, Andrew Cooper wrote: >> @@ -178,6 +179,71 @@ void domain_pause_for_debugger(void) >> send_global_virq(VIRQ_DEBUGGER); >> } >> >> +long gdbsx_domctl(struct domain *d, struct xen_domctl *domctl, bool >> *copyback) > Is there

[ovmf test] 169705: regressions - FAIL

flight 169705 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169705/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

[PATCH v3] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash

When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL pointer. One of several bugs here is known-but-compiled-out subops falling into the default chain and hitting unrelated logic. Remove the CONFIG_GDBSX ifdefary in arch_do_domctl() by implementing gdbsx_domctl() and moving the

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Mon, Apr 25, 2022 at 12:29 PM Tamas K Lengyel wrote: > > > On Mon, Apr 25, 2022, 3:49 AM Jan Beulich wrote: > >> On 22.04.2022 16:07, Tamas K Lengyel wrote: >> > On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel < >> tamas.leng...@intel.com> wrote: >> >> >> >> Allow specify distinct parts of th

Re: [PATCH v2] x86+libxl: correct p2m (shadow) memory pool size calculation

On Mon, Apr 25, 2022 at 10:49:34AM +0200, Jan Beulich wrote: > char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid) > --- a/xen/arch/x86/dom0_build.c > +++ b/xen/arch/x86/dom0_build.c > @@ -317,9 +317,12 @@ unsigned long __init dom0_paging_pages(c > /* Copied from: libxl_get_required_sha

Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration

On 25.04.22 15:09, Juergen Gross wrote: Hello Juergen On 25.04.22 14:02, Oleksandr wrote: On 25.04.22 10:43, Juergen Gross wrote: Hello Juergen Thank you for the feedback. On 08.04.22 20:21, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for co

[ovmf test] 169706: regressions - FAIL

flight 169706 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169706/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration

On Sat, Apr 23, 2022 at 10:39:14AM +0300, Oleksandr wrote: > > On 22.04.22 12:41, Roger Pau Monné wrote: > > > Hello Roger > > > On Fri, Apr 08, 2022 at 09:21:04PM +0300, Oleksandr Tyshchenko wrote: > > > From: Oleksandr Tyshchenko > > > > > > This patch adds basic support for configuring and

Re: [PATCH v2] x86+libxl: correct p2m (shadow) memory pool size calculation

On 25.04.2022 14:59, Roger Pau Monné wrote: > On Mon, Apr 25, 2022 at 10:49:34AM +0200, Jan Beulich wrote: >> char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid) >> --- a/xen/arch/x86/dom0_build.c >> +++ b/xen/arch/x86/dom0_build.c >> @@ -317,9 +317,12 @@ unsigned long __init dom0_paging_pag

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Mon, Apr 25, 2022 at 8:53 AM George Dunlap wrote: > > > > On Mon, Apr 25, 2022 at 12:29 PM Tamas K Lengyel wrote: >> >> >> >> On Mon, Apr 25, 2022, 3:49 AM Jan Beulich wrote: >>> >>> On 22.04.2022 16:07, Tamas K Lengyel wrote: >>> > On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel >>> > wrot

[PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

From: David Vrabel Heap pages can only be safely allocated and freed with interuupts enabled as they may require a TLB flush which will send IPIs (on x86). Normally spinlock debugging would catch calls from the incorrect context, but not from stop_machine_run() action functions as these are call

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 25.04.2022 15:28, David Vrabel wrote: > From: David Vrabel > > Heap pages can only be safely allocated and freed with interuupts > enabled as they may require a TLB flush which will send IPIs (on x86). > > Normally spinlock debugging would catch calls from the incorrect > context, but not fro

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi David, On 25/04/2022 14:28, David Vrabel wrote: From: David Vrabel Heap pages can only be safely allocated and freed with interuupts enabled as they may require a TLB flush which will send IPIs (on x86). Normally spinlock debugging would catch calls from the incorrect context, but not from

Re: [PATCH v3] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash

On 25.04.2022 14:37, Andrew Cooper wrote: > When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL > pointer. One of several bugs here is known-but-compiled-out subops falling > into the default chain and hitting unrelated logic. > > Remove the CONFIG_GDBSX ifdefary in arch_do_dom

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 25.04.2022 15:34, Julien Grall wrote: > On 25/04/2022 14:28, David Vrabel wrote: >> --- a/xen/common/page_alloc.c >> +++ b/xen/common/page_alloc.c >> @@ -162,6 +162,13 @@ >> static char __initdata opt_badpage[100] = ""; >> string_param("badpage", opt_badpage); >> >> +/* >> + * Heap alloca

Re: [PATCH v5 2/6] x86/gdbsx: Rename debug.c to gdbsx.c

On 20.04.2022 16:13, Andrew Cooper wrote: > From: Bobby Eshleman > > debug.c contains only dbg_rw_mem(). Rename it to gdbsx.c. > > Move gdbsx_guest_mem_io(), and the prior setup of iop->remain, from domctl.c > to gdbsx.c, merging it with dbg_rw_mem(). > > Signed-off-by: Bobby Eshleman > Signe

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi Jan, On 25/04/2022 14:37, Jan Beulich wrote: On 25.04.2022 15:34, Julien Grall wrote: On 25/04/2022 14:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@ static char __initdata opt_badpage[100] = ""; string_param("badpage", opt_bad

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi, On 25/04/2022 14:28, David Vrabel wrote: From: David Vrabel Heap pages can only be safely allocated and freed with interuupts The typo I pointed out in v3 has not been addressed. For reminder, this is: s/interupts/interrupts/ Cheers, -- Julien Grall

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 25.04.2022 15:43, Julien Grall wrote: > On 25/04/2022 14:37, Jan Beulich wrote: >> On 25.04.2022 15:34, Julien Grall wrote: >>> On 25/04/2022 14:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@ static char __initdata

[ovmf test] 169707: regressions - FAIL

flight 169707 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169707/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi, On 25/04/2022 14:44, Jan Beulich wrote: On 25.04.2022 15:43, Julien Grall wrote: On 25/04/2022 14:37, Jan Beulich wrote: On 25.04.2022 15:34, Julien Grall wrote: On 25/04/2022 14:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@

Re: [PATCH v2] x86+libxl: correct p2m (shadow) memory pool size calculation

On Mon, Apr 25, 2022 at 03:19:46PM +0200, Jan Beulich wrote: > On 25.04.2022 14:59, Roger Pau Monné wrote: > > On Mon, Apr 25, 2022 at 10:49:34AM +0200, Jan Beulich wrote: > >> char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid) > >> --- a/xen/arch/x86/dom0_build.c > >> +++ b/xen/arch/x86/do

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Wed, Apr 13, 2022 at 09:41:51AM -0400, Tamas K Lengyel wrote: > Allow specify distinct parts of the fork VM to be reset. This is useful when a > fuzzing operation involves mapping in only a handful of pages that are known > ahead of time. Throwing these pages away just to be re-copied immediatel

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 25/04/2022 14:43, Julien Grall wrote: Hi Jan, On 25/04/2022 14:37, Jan Beulich wrote: On 25.04.2022 15:34, Julien Grall wrote: On 25/04/2022 14:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@    static char __initdata opt_badpage[

Re: [PATCH v4 2/2] x86/monitor: Add new monitor event to catch all vmexits

On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote: > Add monitor event that hooks the vmexit handler allowing for both sync and > async monitoring of events. With async monitoring an event is placed on the > monitor ring for each exit and the rest of the vmexit handler resumes > norm

[ovmf test] 169708: regressions - FAIL

flight 169708 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169708/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Mon, Apr 25, 2022 at 10:12 AM Roger Pau Monné wrote: > > On Wed, Apr 13, 2022 at 09:41:51AM -0400, Tamas K Lengyel wrote: > > Allow specify distinct parts of the fork VM to be reset. This is useful > > when a > > fuzzing operation involves mapping in only a handful of pages that are known > >

Re: [PATCH v2] xen: Convert kmap() to kmap_local_page()

On Wed, Apr 20, 2022 at 04:07:36PM +0200, Fabio M. De Francesco wrote: > On mercoledì 20 aprile 2022 15:57:14 CEST Julia Lawall wrote: > > > > On Wed, 20 Apr 2022, Fabio M. De Francesco wrote: > > > > > On mercoledì 20 aprile 2022 15:40:10 CEST Julia Lawall wrote: > > > > > > > > On Wed, 20 Apr 2

[ovmf test] 169709: regressions - FAIL

flight 169709 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH v2] xen: Convert kmap() to kmap_local_page()

On Mon, 25 Apr 2022, Ira Weiny wrote: > On Wed, Apr 20, 2022 at 04:07:36PM +0200, Fabio M. De Francesco wrote: > > On mercoledì 20 aprile 2022 15:57:14 CEST Julia Lawall wrote: > > > > > > On Wed, 20 Apr 2022, Fabio M. De Francesco wrote: > > > > > > > On mercoledì 20 aprile 2022 15:40:10 CEST J

Re: [PATCH v4 2/2] x86/monitor: Add new monitor event to catch all vmexits

On Mon, Apr 25, 2022 at 10:41 AM Roger Pau Monné wrote: > > On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote: > > Add monitor event that hooks the vmexit handler allowing for both sync and > > async monitoring of events. With async monitoring an event is placed on the > > monitor ri

[ovmf test] 169710: regressions - FAIL

flight 169710 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169710/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH v3 1/2] xsm: create idle domain privileged and demote after setup

On 4/25/22 05:44, Roger Pau Monné wrote: > On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote: >> There are now instances where internal hypervisor logic needs to make >> resource >> allocation calls that are protected by XSM checks. The internal hypervisor >> logic >> is represented

Re: [PATCH v3 2/2] flask: implement xsm_set_system_active

On 4/22/22 12:58, Jason Andryuk wrote: > On Fri, Apr 22, 2022 at 12:35 PM Daniel P. Smith > wrote: >> >> This commit implements full support for starting the idle domain privileged >> by >> introducing a new flask label xenboot_t which the idle domain is labeled with >> at creation. It then prov

[ovmf test] 169711: regressions - FAIL

flight 169711 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169711/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

DomU Windows Server Essentials crashes with xen 4.16 but works with xen 4.14

Hello Everyone, I have some xen servers I recently tried to update from xen 4.14 to xen 4.16 Everything worked without problem, except for the Windows Server Essentials DomUs. With xen 4.16 those domains crashed (reproducable) during boot - KMODE_EXCEPTION_NOT_HANDLED. I tried to install a

[PATCH v4 0/2] Adds starting the idle domain privileged

This series makes it so that the idle domain is started privileged under the default policy, which the SILO policy inherits, and under the flask policy. It then introduces a new one-way XSM hook, xsm_transition_running, that is hooked by an XSM policy to transition the idle domain to its running pr

[PATCH v4 1/2] xsm: create idle domain privileged and demote after setup

There are new capabilities, dom0less and hyperlaunch, that introduce internal hypervisor logic which needs to make resource allocation calls that are protected by XSM access checks. This creates an issue as a subset of the hypervisor code is executed under a system domain, the idle domain, that is

[PATCH v4 2/2] flask: implement xsm_set_system_active

This commit implements full support for starting the idle domain privileged by introducing a new flask label xenboot_t which the idle domain is labeled with at creation. It then provides the implementation for the XSM hook xsm_set_system_active to relabel the idle domain to the existing xen_t flas

[ovmf test] 169712: regressions - FAIL

flight 169712 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169712/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

[PATCH] x86/nospec: Fix evaluate_nospec() code generation under Clang

It turns out that evaluate_nospec() code generation is not safe under Clang. Given: void eval_nospec_test(int x) { if ( evaluate_nospec(x) ) asm volatile ("nop #true" ::: "memory"); else asm volatile ("nop #false" ::: "memory"); } Clang emits: : 0

[PATCH] xsm/flask: Fix build with Clang 13

Clang 13 chokes with: In file included from xsm/flask/flask_op.c:780: xsm/flask/flask_op.c:698:33: error: passing 4-byte aligned argument to 8-byte aligned parameter 1 of 'flask_ocontext_add' may result in an unaligned pointer access [-Werror,-Walign-mismatch] rv = flask_ocontext

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi, On 25/04/2022 15:13, David Vrabel wrote: On 25/04/2022 14:43, Julien Grall wrote: Hi Jan, On 25/04/2022 14:37, Jan Beulich wrote: On 25.04.2022 15:34, Julien Grall wrote: On 25/04/2022 14:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +16

[ovmf test] 169713: regressions - FAIL

flight 169713 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169713/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

  1   2   >