flight 170079 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Julien,
> On 3 May 2022, at 19:47, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 03/05/2022 10:38, Bertrand Marquis wrote:
>> This patch is adding sb instruction support when it is supported by a
>> CPU on arm64.
>> To achieve this, the "sb" macro is moved to sub-arch macros.h so that we
>> ca
Hi Julien,
> On 3 May 2022, at 19:17, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 03/05/2022 10:38, Bertrand Marquis wrote:
>> SMCC_WORKAROUND_3 is handling both Spectre v2 and spectre BHB.
>> So when a guest is asking if we support workaround 1, tell yes if we
>> apply workaround 3 on exceptio
On Tue, 2022-05-03 at 18:44 -0700, Kees Cook wrote:
>
> For example, using the most complicated helper, mem_to_flex_dup():
>
> /* Flexible array struct with members identified. */
> struct something {
> int mode;
> DECLARE_FLEX_ARRAY_ELEMENTS_COUNT(int, how_many);
>
On Tue, 2022-05-03 at 18:44 -0700, Kees Cook wrote:
>
> @@ -2277,7 +2274,7 @@ cfg80211_update_notlisted_nontrans(struct wiphy *wiphy,
> size_t ielen = len - offsetof(struct ieee80211_mgmt,
> u.probe_resp.variable);
> size_t new_ie_len;
> - struct
Hi Julien,
> On 3 May 2022, at 19:08, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 03/05/2022 10:38, Bertrand Marquis wrote:
>> Sync arm64 sysreg bit shift definitions with status of Linux kernel as
>> of 5.18-rc3 version (linux commit b2d229d4ddb1).
>> Sync ID registers sanitization with the st
On 19.04.22 10:01, Juergen Gross wrote:
On 24.03.22 15:01, Juergen Gross wrote:
In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall handler calls via the function array
by automat
flight 170083 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 04/05/2022 08:24, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 3 May 2022, at 19:47, Julien Grall wrote:
A new cpuerrata capability is introduced to enable the alternative
'sb' is definitely not an erratum. Errata are for stuff that are meant to be
specific to one (or multi
On 04.05.2022 08:41, Michal Orzel wrote:
> On 03.05.2022 19:44, Julien Grall wrote:
>> On 28/04/2022 10:46, Michal Orzel wrote:
>>> @@ -89,10 +90,12 @@ int replace_grant_host_mapping(unsigned long gpaddr,
>>> mfn_t mfn,
>>> })
>>> #define gnttab_shared_gfn(d, t, i)
flight 170064 qemu-mainline real [real]
flight 170081 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170064/
http://logs.test-lab.xenproject.org/osstest/logs/170081/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
On 04/05/2022 08:39, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 3 May 2022, at 19:08, Julien Grall wrote:
Hi Bertrand,
On 03/05/2022 10:38, Bertrand Marquis wrote:
Sync arm64 sysreg bit shift definitions with status of Linux kernel as
of 5.18-rc3 version (linux commit b2d229d4ddb1).
Sync
On 03.05.2022 15:22, Juergen Gross wrote:
> Some drivers are using pat_enabled() in order to test availability of
> special caching modes (WC and UC-). This will lead to false negatives
> in case the system was booted e.g. with the "nopat" variant and the
> BIOS did setup the PAT MSR supporting the
flight 170085 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170071 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170014
test-armhf-armhf-libvirt 16 save
On 04.05.22 10:31, Jan Beulich wrote:
On 03.05.2022 15:22, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false negatives
in case the system was booted e.g. with the "nopat" variant and the
BIOS did
flight 170087 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170087/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 03.05.2022 16:50, Jan Beulich wrote:
> On 03.05.2022 15:00, Roger Pau Monné wrote:
>> On Mon, Apr 25, 2022 at 10:34:23AM +0200, Jan Beulich wrote:
>>> While already the case for PVH, there's no reason to treat PV
>>> differently here, though of course the addresses get taken from another
>>> sou
On 03.05.2022 16:49, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:34:59AM +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
Hi Julien,
> On 4 May 2022, at 09:20, Julien Grall wrote:
>
>
>
> On 04/05/2022 08:39, Bertrand Marquis wrote:
>> Hi Julien,
> Hi,
>
>>> On 3 May 2022, at 19:08, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 03/05/2022 10:38, Bertrand Marquis wrote:
Sync arm64 sysreg bit shift d
On 04.05.2022 11:14, Juergen Gross wrote:
> On 04.05.22 10:31, Jan Beulich wrote:
>> On 03.05.2022 15:22, Juergen Gross wrote:
>>> Some drivers are using pat_enabled() in order to test availability of
>>> special caching modes (WC and UC-). This will lead to false negatives
>>> in case the system w
flight 170078 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Dear xen developers,
When xen is deployed in a way that no linux bridges exists on the host,
then
https://github.com/xen-project/xen/blob/stable-4.14/tools/xenstat/libxenstat/src/xenstat_linux.c#L313
will get devBridge as empty string, and then conditions on
https://github.com/xen-project/xen
flight 170090 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, May 03, 2022 at 04:44:45PM +0200, Jan Beulich wrote:
> On 03.05.2022 14:37, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:33:32AM +0200, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/iommu.c
> >> +++ b/xen/drivers/passthrough/iommu.c
> >> @@ -307,11 +338,10 @@ int iommu_map(
On Wed, May 04, 2022 at 11:32:51AM +0200, Jan Beulich wrote:
> On 03.05.2022 16:50, Jan Beulich wrote:
> > On 03.05.2022 15:00, Roger Pau Monné wrote:
> >> On Mon, Apr 25, 2022 at 10:34:23AM +0200, Jan Beulich wrote:
> >>> While already the case for PVH, there's no reason to treat PV
> >>> differen
Hi Julien,
> On 3 May 2022, at 4:52 pm, Julien Grall wrote:
>
>
>
> On 28/04/2022 15:11, Rahul Singh wrote:
>> Hi Julien,
>
> Hi Rahul,
>
>>> On 28 Apr 2022, at 1:59 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 28/04/2022 11:00, Rahul Singh wrote:
Hi Julien,
> On 27 Apr 2022, at 6
On 04.05.2022 12:30, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 11:32:51AM +0200, Jan Beulich wrote:
>> On 03.05.2022 16:50, Jan Beulich wrote:
>>> On 03.05.2022 15:00, Roger Pau Monné wrote:
On Mon, Apr 25, 2022 at 10:34:23AM +0200, Jan Beulich wrote:
> While already the case for PV
flight 170094 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, May 04, 2022 at 11:46:37AM +0200, Jan Beulich wrote:
> On 03.05.2022 16:49, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:34:59AM +0200, Jan Beulich wrote:
> >> For large page mappings to be easily usable (i.e. in particular without
> >> un-shattering of smaller page mappings) and f
Hi Julien,
> On 3 May 2022, at 4:58 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 27/04/2022 17:14, Rahul Singh wrote:
>> MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
>> not enabled before mapping the collection table using MAPC command.
>> Enable the LPIs using GICR_CT
On 04.05.2022 10:13, Jan Beulich wrote:
> On 04.05.2022 08:41, Michal Orzel wrote:
>> On 03.05.2022 19:44, Julien Grall wrote:
>>> On 28/04/2022 10:46, Michal Orzel wrote:
@@ -89,10 +90,12 @@ int replace_grant_host_mapping(unsigned long gpaddr,
mfn_t mfn,
})
#define gn
flight 170097 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Bertrand,
On 04/05/2022 10:49, Bertrand Marquis wrote:
On 4 May 2022, at 09:20, Julien Grall wrote:
On 04/05/2022 08:39, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 3 May 2022, at 19:08, Julien Grall wrote:
Hi Bertrand,
On 03/05/2022 10:38, Bertrand Marquis wrote:
Sync arm64 sysreg
Hi,
On 04/05/2022 12:25, Rahul Singh wrote:
On 3 May 2022, at 4:58 pm, Julien Grall wrote:
On 27/04/2022 17:14, Rahul Singh wrote:
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
not enabled before mapping the collection table using MAPC command.
Enable the LPIs using GI
On Wed, May 04, 2022 at 12:51:25PM +0200, Jan Beulich wrote:
> On 04.05.2022 12:30, Roger Pau Monné wrote:
> > On Wed, May 04, 2022 at 11:32:51AM +0200, Jan Beulich wrote:
> >> On 03.05.2022 16:50, Jan Beulich wrote:
> >>> On 03.05.2022 15:00, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 1
On 04.05.2022 14:01, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 12:51:25PM +0200, Jan Beulich wrote:
>> On 04.05.2022 12:30, Roger Pau Monné wrote:
>>> Right, ->iomem_caps is indeed too wide for our purpose. What
>>> about using something like:
>>>
>>> else if ( is_pv_domain(d) )
>>> {
>>>
flight 170072 linux-linus real [real]
flight 170095 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170072/
http://logs.test-lab.xenproject.org/osstest/logs/170095/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
Hi Julien,
> On 4 May 2022, at 12:59 pm, Julien Grall wrote:
>
> Hi,
>
> On 04/05/2022 12:25, Rahul Singh wrote:
>>> On 3 May 2022, at 4:58 pm, Julien Grall wrote:
>>> On 27/04/2022 17:14, Rahul Singh wrote:
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
not e
On 04.05.2022 13:20, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 11:46:37AM +0200, Jan Beulich wrote:
>> On 03.05.2022 16:49, Roger Pau Monné wrote:
>>> On Mon, Apr 25, 2022 at 10:34:59AM +0200, Jan Beulich wrote:
For large page mappings to be easily usable (i.e. in particular without
>>>
On 03/05/2022 18:56, Evan Green wrote:
> Hi Guilherme,
> [...]
>> Do you agree with that, or prefer really a parameter in
>> gsmi_shutdown_reason() ? I'll follow your choice =)
>
> I'm fine with either, thanks for the link. Mostly I want to make sure
> other paths to gsmi_shutdown_reason() aren't
On Wed, May 04, 2022 at 02:12:58PM +0200, Jan Beulich wrote:
> On 04.05.2022 14:01, Roger Pau Monné wrote:
> > On Wed, May 04, 2022 at 12:51:25PM +0200, Jan Beulich wrote:
> >> On 04.05.2022 12:30, Roger Pau Monné wrote:
> >>> Right, ->iomem_caps is indeed too wide for our purpose. What
> >>> abou
flight 170099 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 03.05.2022 18:20, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:35:45AM +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 Wed, Apr 27, 2022 at 11:52 AM Tamas K Lengyel
wrote:
>
> Need to separately specify if the reset is for the memory or for the VM state,
> or both.
>
> Signed-off-by: Tamas K Lengyel
> ---
> v5: split from the hypervisor-side patch
Patch ping. Could a toolstack maintainer please take a look at
On Wed, Apr 27, 2022 at 11:51 AM 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
> normally.
On 04.05.2022 15:00, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 02:12:58PM +0200, Jan Beulich wrote:
>> On 04.05.2022 14:01, Roger Pau Monné wrote:
>>> On Wed, May 04, 2022 at 12:51:25PM +0200, Jan Beulich wrote:
On 04.05.2022 12:30, Roger Pau Monné wrote:
> Right, ->iomem_caps is in
On 28.04.2022 05:01, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1443,6 +1443,10 @@ static void free_heap_pages(
>
> ASSERT(order <= MAX_ORDER);
>
> +if ( pg->count_info & PGC_reserved )
> +/* Reserved page shall not go back to the h
On 27.04.2022 11:27, Penny Zheng wrote:
> There is a slim chance that free_heap_pages() may decide to merge a chunk
> from the static region(PGC_reserved) with the about-to-be-free chunk.
>
> So in order to avoid the above scenario, this commit updates free_heap_pages()
> to check whether the pred
On 27.04.2022 11:27, Penny Zheng wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -245,6 +245,29 @@ static void populate_physmap(struct memop_args *a)
>
> mfn = _mfn(gpfn);
> }
> +else if ( is_domain_using_staticmem(d) )
> +
On Wed, May 04, 2022 at 03:19:16PM +0200, Jan Beulich wrote:
> On 04.05.2022 15:00, Roger Pau Monné wrote:
> > On Wed, May 04, 2022 at 02:12:58PM +0200, Jan Beulich wrote:
> >> On 04.05.2022 14:01, Roger Pau Monné wrote:
> >>> On Wed, May 04, 2022 at 12:51:25PM +0200, Jan Beulich wrote:
> On 0
On 04.05.2022 15:46, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 03:19:16PM +0200, Jan Beulich wrote:
>> On 04.05.2022 15:00, Roger Pau Monné wrote:
>>> On Wed, May 04, 2022 at 02:12:58PM +0200, Jan Beulich wrote:
On 04.05.2022 14:01, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 1
On Wed, May 04, 2022 at 02:27:14PM +0200, Jan Beulich wrote:
> On 04.05.2022 13:20, Roger Pau Monné wrote:
> > On Wed, May 04, 2022 at 11:46:37AM +0200, Jan Beulich wrote:
> >> On 03.05.2022 16:49, Roger Pau Monné wrote:
> >>> On Mon, Apr 25, 2022 at 10:34:59AM +0200, Jan Beulich wrote:
> >>> It wo
flight 170102 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170102/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 04.05.2022 15:55, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 02:27:14PM +0200, Jan Beulich wrote:
>> On 04.05.2022 13:20, Roger Pau Monné wrote:
>>> On Wed, May 04, 2022 at 11:46:37AM +0200, Jan Beulich wrote:
On 03.05.2022 16:49, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 1
On Wed, May 04, 2022 at 03:07:24PM +0200, Jan Beulich wrote:
> On 03.05.2022 18:20, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:35:45AM +0200, Jan Beulich wrote:
> >> For vendor specific code to support superpages we need to be able to
> >> deal with a superpage mapping replacing an inter
On Wed, May 04, 2022 at 08:42:46AM +0300, Kalle Valo wrote:
> Kees Cook writes:
>
> > As part of the work to perform bounds checking on all memcpy() uses,
> > replace the open-coded a deserialization of bytes out of memory into a
> > trailing flexible array by using a flex_array.h helper to perfo
flight 170106 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, May 04, 2022 at 09:28:46AM +0200, Johannes Berg wrote:
> On Tue, 2022-05-03 at 18:44 -0700, Kees Cook wrote:
> >
> > @@ -2277,7 +2274,7 @@ cfg80211_update_notlisted_nontrans(struct wiphy
> > *wiphy,
> > size_t ielen = len - offsetof(struct ieee80211_mgmt,
> >
On Wed, May 04, 2022 at 03:55:09PM +0200, Jan Beulich wrote:
> On 04.05.2022 15:46, Roger Pau Monné wrote:
> > On Wed, May 04, 2022 at 03:19:16PM +0200, Jan Beulich wrote:
> >> On 04.05.2022 15:00, Roger Pau Monné wrote:
> >>> On Wed, May 04, 2022 at 02:12:58PM +0200, Jan Beulich wrote:
> On 0
On Tue, May 03, 2022 at 06:44:29PM -0700, Kees Cook wrote:
> As part of the work to perform bounds checking on all memcpy() uses,
> replace the open-coded a deserialization of bytes out of memory into a
> trailing flexible array by using a flex_array.h helper to perform the
> allocation, bounds ch
On Wed, May 04, 2022 at 09:25:56AM +0200, Johannes Berg wrote:
> On Tue, 2022-05-03 at 18:44 -0700, Kees Cook wrote:
> >
> > For example, using the most complicated helper, mem_to_flex_dup():
> >
> > /* Flexible array struct with members identified. */
> > struct something {
> > i
Add a simple infrastructure for setting, resetting and querying
platform feature flags.
Flags can be either global or architecture specific.
Signed-off-by: Juergen Gross
---
V2:
- rename set/reset functions to platform_[set|clear]() (Boris Petkov,
Heiko Carstens)
- move function implementation
In another patch series [1] the need has come up to have support for
a generic feature flag infrastructure.
This patch series is introducing that infrastructure and adds the first
use case.
I have decided to use a similar interface as the already known x86
cpu_has() function. As the new infrastru
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
---
V2:
- move setting of PLATFORM_VIRTIO_RES
On Mon, Apr 25, 2022 at 10:36:42AM +0200, Jan Beulich wrote:
> 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 Beuli
From: Kees Cook
> Sent: 04 May 2022 16:38
...
> > > struct something *instance = NULL;
> > > int rc;
> > >
> > > rc = mem_to_flex_dup(&instance, byte_array, count, GFP_KERNEL);
> > > if (rc)
> > > return rc;
> >
> > This seems rather awkward, having to set it to NULL, then c
flight 170111 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170111/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is observed.
As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be reported if the MAPC command has tried to map a collection to a core
that does not have LPIs enabled
This patch introduces a new feature to support the signaling between
two domains in dom0less system.
Signed-off-by: Rahul Singh
---
v2 changes:
- switch to the one-subnode-per-evtchn under xen,domain" compatible node.
- Add more detail about event-channel
---
docs/designs/dom0less-evtchn.md | 1
flight 170114 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, May 04, 2022 at 11:00:38AM +0800, David Gow wrote:
> On Wed, May 4, 2022 at 9:47 AM Kees Cook wrote:
> >
> > Add tests for the new flexible array structure helpers. These can be run
> > with:
> >
> > make ARCH=um mrproper
> > ./tools/testing/kunit/kunit.py config
>
> Nit: it shouldn't
Hello Jens,
Jens Wiklander writes:
> This commit fixes a case overlooked in [1].
>
> There are two kinds of shared memory buffers used by OP-TEE:
> 1. Normal payload buffer
> 2. Internal command structure buffers
>
> The internal command structure buffers are represented with a shadow
> copy i
On Wed, Apr 27, 2022 at 07:49:01PM -0300, Guilherme G. Piccoli wrote:
> Many other place in the kernel prefer the latter, so let's keep
> it consistent in MIPS code as well. Also, removes a useless header.
>
> Cc: Thomas Bogendoerfer
> Signed-off-by: Guilherme G. Piccoli
> ---
> arch/mips/sgi-i
On 04/05/2022 17:32, Thomas Bogendoerfer wrote:
> [...]
>
> applied to mips-next.
>
> Thomas.
>
Thanks a bunch Thomas =)
flight 170117 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, 4 May 2022, Volodymyr Babchuk wrote:
> Hello Jens,
>
> Jens Wiklander writes:
>
> > This commit fixes a case overlooked in [1].
> >
> > There are two kinds of shared memory buffers used by OP-TEE:
> > 1. Normal payload buffer
> > 2. Internal command structure buffers
> >
> > The internal
flight 170121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170125 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi all,
Currently dom0less guests cannot use PV drivers because they don't have
access to xenstore. Also, the hypervisor node in device tree is missing
so they don't detect that they are running on Xen (thus, they don't try
to enable PV interfaces.)
This patch series enables dom0less guests (on A
From: Stefano Stabellini
Implement extended regions for dom0less domUs. The implementation is
based on the libxl implementation.
Also update docs for the ext_regions command line option.
Signed-off-by: Stefano Stabellini
Reviewed-by: Luca Fancellu
CC: olekst...@gmail.com
---
Changes in v6:
-
From: Stefano Stabellini
Document how to use the feature and how the implementation works.
Signed-off-by: Stefano Stabellini
Reviewed-by: Luca Fancellu
---
docs/features/dom0less.pandoc | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/do
From: Stefano Stabellini
Introduce a new "xen,enhanced" dom0less property to enable/disable PV
driver interfaces for dom0less guests. Currently only "enabled" and
"disabled" are supported property values (and empty). Leave the option
open to implement further possible values in the future (e.g.
"
From: Luca Miccio
When xs_introduce_domain is called, send out a notification on the
xenstore event channel so that any (dom0less) domain waiting for the
xenstore interface to be ready can continue with the initialization.
Before sending the notification, clear XENSTORE_RECONNECTING.
The extra n
From: Stefano Stabellini
When the length of the string is zero of_property_read_string should
return -ENODATA according to the description of the function.
However, of_property_read_string doesn't check prop->length. If
prop->length is zero, return -ENODATA.
Without this patch the following com
From: Luca Miccio
Export evtchn_alloc_unbound and make it __must_check.
If "xen,enhanced" is enabled, then add to dom0less domains:
- the hypervisor node in device tree
- the xenstore event channel
The xenstore event channel is also used for the first notification to
let the guest know that xe
From: Luca Miccio
Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.
The application sets "connection" to XENSTORE_RECONNECT on the xenstore
page before calling xs_introduce_domain to sign
From: Stefano Stabellini
Sync the xs_wire.h header file in Linux with the one in Xen.
Signed-off-by: Stefano Stabellini
---
include/xen/interface/io/xs_wire.h | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/include/xen/interface/io/xs_wire.h
Hi all,
This small Linux patch series implements support for initializing
xenstore later, if not immediately available at boot time. It enables
dom0less + PV drivers support.
Luca Miccio (1):
xen: add support for initializing xenstore later as HVM domain
Stefano Stabellini (1):
xen:
From: Luca Miccio
When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.
In that case, wait for a notification on the xenstore event channel,
then complete the xenstore
flight 170110 qemu-mainline real [real]
flight 170123 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170110/
http://logs.test-lab.xenproject.org/osstest/logs/170123/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
flight 170127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170116 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170116/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170072
test-armhf-armhf-libvirt 16 saver
flight 170122 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170122/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 170131 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
xmalloc() will use a pool for allocation smaller than a page.
The pool is extended only when there are no more space. At which
point, alloc_xenheap_pages() is called to add more memory.
xmalloc() must be protected by ASSERT_ALLOC_CONTEXT. It should not
rely on pool expanding to trigger the ASSERT_
With the enhanced ASSERT_ALLOC_CONTEXT, calling request_irq before
local_irq_enable on secondary cores on Arm will lead to
(XEN) Xen call trace:
(XEN) [<0021d86c>] alloc_xenheap_pages+0x74/0x194 (PC)
(XEN) [<0021d864>] alloc_xenheap_pages+0x6c/0x194 (LR)
(XEN) [<00229e90>]
With the enhanced ASSERT_ALLOC_CONTEXT, calling request_irq before
local_irq_enable on secondary cores will lead to
(XEN) Xen call trace:
(XEN) [<0021d86c>] alloc_xenheap_pages+0x74/0x194 (PC)
(XEN) [<0021d864>] alloc_xenheap_pages+0x6c/0x194 (LR)
(XEN) [<00229e90>] xmalloc
Hi,
> -Original Message-
> Subject: [PATCH 1/2] xen/arm: Defer request_irq on secondary CPUs after
> local_irq_enable
>
> With the enhanced ASSERT_ALLOC_CONTEXT, calling request_irq before
> local_irq_enable on secondary cores will lead to
>
> (XEN) Xen call trace:
> (XEN) [<002
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
1 - 100 of 111 matches
Mail list logo
