On 02.05.2023 13:05, Jan Beulich wrote:
> On 02.05.2023 12:51, Roger Pau Monné wrote:
>> On Tue, May 02, 2023 at 12:28:55PM +0200, Jan Beulich wrote:
>>> On 02.05.2023 11:54, Andrew Cooper wrote:
On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> @@ -670,6 +674,11 @@ trampoline_setup:
>
On Tue, May 02, 2023 at 08:53:31AM +0200, Jan Beulich wrote:
> I'm also having a hard time seeing what failure case the test ended
> up encountering: There are only two errors which can occur - one
> from the XSM hook (which is mishandled, and I'll make a separate
> patch for that) and the other
On 02.05.2023 12:51, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 12:28:55PM +0200, Jan Beulich wrote:
>> On 02.05.2023 11:54, Andrew Cooper wrote:
>>> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
Ensure that the base address is 2M aligned, or else the page table
entries created
On Tue, May 02, 2023 at 06:43:33AM -0400, Daniel P. Smith wrote:
>
>
> On 5/2/23 03:17, Jan Beulich wrote:
> > Unlike for XEN_DOMCTL_getdomaininfo, where the XSM check is intended to
> > cause the operation to fail, in the loop here it ought to merely
> > determine whether information for the
On some of the Arm32 based systems (eg Cortex-R52), smpboot is supported.
In these systems PSCI may not always be supported. In case of Cortex-R52, there
is no EL3 or secure mode. Thus, PSCI is not supported as it requires EL3.
Thus, we use 'spin-table' mechanism to boot the secondary cpus. The
On 02.05.2023 12:43, Daniel P. Smith wrote:
> On 5/2/23 03:17, Jan Beulich wrote:
>> Unlike for XEN_DOMCTL_getdomaininfo, where the XSM check is intended to
>> cause the operation to fail, in the loop here it ought to merely
>> determine whether information for the domain at hand may be reported
On 25.04.2023 16:39, Marek Marczykowski-Górecki wrote:
> pci_serial_early_init() enables PCI_COMMAND_IO for IO-based UART
> devices, add setting PCI_COMMAND_MEMORY for MMIO-based UART devices too.
This sentence is odd, as by its grammar it looks to describe the current
situation only. The
On Tue, May 02, 2023 at 12:28:55PM +0200, Jan Beulich wrote:
> On 02.05.2023 11:54, Andrew Cooper wrote:
> > On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> >> Ensure that the base address is 2M aligned, or else the page table
> >> entries created would be corrupt as reserved bits on the PDE end
On 5/2/23 03:17, Jan Beulich wrote:
Unlike for XEN_DOMCTL_getdomaininfo, where the XSM check is intended to
cause the operation to fail, in the loop here it ought to merely
determine whether information for the domain at hand may be reported
back. Therefore if on the last iteration the hook
On 02/05/2023 11:28 am, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 10:54:55AM +0100, Andrew Cooper wrote:
>> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
>>> Ensure that the base address is 2M aligned, or else the page table
>>> entries created would be corrupt as reserved bits on the PDE
On 02.05.2023 12:28, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 10:54:55AM +0100, Andrew Cooper wrote:
>> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
>>> Ensure that the base address is 2M aligned, or else the page table
>>> entries created would be corrupt as reserved bits on the PDE end
On Tue, May 02, 2023 at 10:43:13AM +0100, Andrew Cooper wrote:
> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> > When booting the BSP the portion of the code executed from the
> > trampoline page will be using the GDT located in the hypervisor
> > .text.head section rather than the GDT located
On Tue, May 02, 2023 at 10:54:55AM +0100, Andrew Cooper wrote:
> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> > Ensure that the base address is 2M aligned, or else the page table
> > entries created would be corrupt as reserved bits on the PDE end up
> > set.
> >
> > We have found a broken
On 02.05.2023 11:54, Andrew Cooper wrote:
> On 02/05/2023 10:22 am, Roger Pau Monne wrote:
>> Ensure that the base address is 2M aligned, or else the page table
>> entries created would be corrupt as reserved bits on the PDE end up
>> set.
>>
>> We have found a broken firmware where the loader
On Tue, May 02, 2023 at 12:18:06PM +0200, Jan Beulich wrote:
> On 02.05.2023 12:10, Roger Pau Monné wrote:
> > On Wed, Apr 26, 2023 at 02:55:20PM +, Ruben Hakobyan wrote:
> >> Xen reserves a constant number of pages that can be used for mapping
> >> MSI-X tables. This limit is defined by
On Thu, Apr 27, 2023 at 02:29:06PM +0200, Jan Beulich wrote:
> While I was the one to introduce it, I don't think it is correct: A
> bogus continuation call issued by a tool stack domain may find another
> continuation in progress. IOW we've been asserting caller controlled
> state (which is
On 02.05.2023 12:10, Roger Pau Monné wrote:
> On Wed, Apr 26, 2023 at 02:55:20PM +, Ruben Hakobyan wrote:
>> Xen reserves a constant number of pages that can be used for mapping
>> MSI-X tables. This limit is defined by FIX_MSIX_MAX_PAGES in fixmap.h.
>>
>> Reserving a fixed number of pages
flight 180500 linux-linus real [real]
flight 180503 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180500/
http://logs.test-lab.xenproject.org/osstest/logs/180503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Wed, Apr 26, 2023 at 02:55:20PM +, Ruben Hakobyan wrote:
> Xen reserves a constant number of pages that can be used for mapping
> MSI-X tables. This limit is defined by FIX_MSIX_MAX_PAGES in fixmap.h.
>
> Reserving a fixed number of pages could result in an -ENOMEM if a
> device requests a
On 26.04.23 18:40, Ross Lagerwall wrote:
The existing code silently converts read operations with the
REQ_FUA bit set into write-barrier operations. This results in data
loss as the backend scribbles zeroes over the data instead of returning
it.
While the REQ_FUA bit doesn't make sense on a
On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> Ensure that the base address is 2M aligned, or else the page table
> entries created would be corrupt as reserved bits on the PDE end up
> set.
>
> We have found a broken firmware where the loader would end up loading
> Xen at a non 2M aligned
On 02/05/2023 10:22 am, Roger Pau Monne wrote:
> When booting the BSP the portion of the code executed from the
> trampoline page will be using the GDT located in the hypervisor
> .text.head section rather than the GDT located in the trampoline page.
It's more subtle than this.
gdt_boot_descr
On 02.05.2023 11:33, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 10:27:39AM +0100, Andrew Cooper wrote:
>> On 02/05/2023 8:17 am, Jan Beulich wrote:
>>> The hook being able to deny access to data for certain domains means
>>> that no caller can assume to have a system-wide picture when
On 02/05/2023 10:33 am, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 10:27:39AM +0100, Andrew Cooper wrote:
>> On 02/05/2023 8:17 am, Jan Beulich wrote:
>>> The hook being able to deny access to data for certain domains means
>>> that no caller can assume to have a system-wide picture when
flight 180502 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180502/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 23c71536efbebed57942947668f470f934324477
baseline version:
ovmf
On Tue, May 02, 2023 at 10:27:39AM +0100, Andrew Cooper wrote:
> On 02/05/2023 8:17 am, Jan Beulich wrote:
> > The hook being able to deny access to data for certain domains means
> > that no caller can assume to have a system-wide picture when holding the
> > results.
> >
> > Wouldn't it make
On 02/05/2023 8:17 am, Jan Beulich wrote:
> The hook being able to deny access to data for certain domains means
> that no caller can assume to have a system-wide picture when holding the
> results.
>
> Wouldn't it make sense to permit the function to merely "count" domains?
> While racy in
Ensure that the base address is 2M aligned, or else the page table
entries created would be corrupt as reserved bits on the PDE end up
set.
We have found a broken firmware where the loader would end up loading
Xen at a non 2M aligned region, and that caused a very difficult to
debug triple fault.
When booting the BSP the portion of the code executed from the
trampoline page will be using the GDT located in the hypervisor
.text.head section rather than the GDT located in the trampoline page.
If skip_realmode is not set the GDT located in the trampoline page
will be loaded after having
Hello,
The following series contain two minor improvements for early boot: the
first one is an alignment check when building the initial page tables,
the second is a consistency fix for the GDT used by the BSP for the
trampoline code.
Both are a result of some debugging work done on a system
On 28.04.2023 12:26, Ruben Hakobyan wrote:
> Introduced as part of XSA-228, the maptrack_freelist_lock is meant to
> protect all accesses to entries in the vCPU freelist as well as the
> head and tail pointers.
>
> However, this principle is violated twice in get_maptrack_handle(),
> where the
On 01.05.2023 22:03, Stewart Hildebrand wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1305,7 +1305,7 @@ __initcall(setup_dump_pcidevs);
>
> static int iommu_add_device(struct pci_dev *pdev)
> {
> -const struct domain_iommu *hd;
> +const struct
On 01.05.2023 22:03, Stewart Hildebrand wrote:
> @@ -228,6 +229,9 @@ int iommu_release_dt_devices(struct domain *d);
> * (IOMMU is not enabled/present or device is not connected to it).
> */
> int iommu_add_dt_device(struct dt_device_node *np);
> +#ifdef CONFIG_HAS_PCI
> +int
On 02.05.2023 09:31, Jan Beulich wrote:
> On 02.05.2023 07:48, Olaf Hering wrote:
>> The next push to xen.git#staging will trigger a build failure in the
>> refreshed Leap docker image.
>>
>> For some reason HAS_CC_CET_IBT will evaluate to true. I think the
>> significant change is the binutils
On 02.05.2023 07:48, Olaf Hering wrote:
> The next push to xen.git#staging will trigger a build failure in the
> refreshed Leap docker image.
>
> For some reason HAS_CC_CET_IBT will evaluate to true. I think the significant
> change is the binutils upgrade from 2.37 to 2.39 in November 2022.
>
On 30.04.2023 16:46, Juergen Gross wrote:
> In case XSM is active, the handling of XEN_SYSCTL_getdomaininfolist
> can fail if the last domain scanned isn't allowed to be accessed by
> the calling domain (i.e. xsm_getdomaininfo(XSM_HOOK, d) is failing).
>
> Fix that by just ignoring scanned
Unlike for XEN_DOMCTL_getdomaininfo, where the XSM check is intended to
cause the operation to fail, in the loop here it ought to merely
determine whether information for the domain at hand may be reported
back. Therefore if on the last iteration the hook results in denial,
this should not affect
On 02.05.2023 05:59, Stefano Stabellini wrote:
> xen: fix broken XEN_SYSCTL_getdomaininfolist hypercall
>
> XEN_SYSCTL_getdomaininfolist doesn't actually update the guest
> num_domains field, only its local copy. Fix that.
This isn't true, at least not always / unconditionally. "copyback" is
On 28.04.2023 22:05, Oleksii wrote:
> Hi Jan,
>
> On Mon, 2023-04-24 at 17:35 +0200, Jan Beulich wrote:
>> On 24.04.2023 17:16, Oleksii wrote:
>>> On Mon, 2023-04-24 at 12:18 +0200, Jan Beulich wrote:
On 21.04.2023 18:01, Oleksii wrote:
> On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich
On 29.04.2023 12:05, Oleksii wrote:
For
RISC-V, I would recommend to make sure the struct page_info will
never
cross a cache boundary.
> Do you mean that size(struct page_info) <= cache line size?
I don't think that's what was meant. Instead I expect the goal is for no
struct
On 30.04.2023 19:16, Elliott Mitchell wrote:
> On Mon, Mar 20, 2023 at 09:28:20AM +0100, Jan Beulich wrote:
>> On 20.03.2023 09:14, Jan Beulich wrote:
>>> On 17.03.2023 18:26, Elliott Mitchell wrote:
On Fri, Mar 17, 2023 at 09:22:09AM +0100, Jan Beulich wrote:
> On 16.03.2023 23:03,
101 - 141 of 141 matches
Mail list logo
