ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
> >> +else
> >> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> >> +break;
> >
> > With the recently posted kernel patch
> > https://lore.kernel.org/all/20240410-ff
On 2024-04-10 21:35, Andrew Cooper wrote:
Resolves an R7.2 violation.
Thanks, I was going to suggest the same change. This will resolve the
failure of the CI MISRA analysis on GitLab.
Reviewed-by: Nicola Vetrini
Fixes: c286bb93d20c ("xen/spinlock: support higher number of cpus")
flight 185290 linux-linus real [real]
flight 185305 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185290/
http://logs.test-lab.xenproject.org/osstest/logs/185305/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> On 27.03.2024 18:27, Elliott Mitchell wrote:
> > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> >>>
> >>> In fact when running into trouble, the
On Wed, Apr 10, 2024 at 05:36:34PM +0200, Andrei Semenov wrote:
> This patch series initiate work on AMD SEV technology implementation in Xen.
> SEV stands for "Secure Encrypted Virtualization" and allows the memory
> contents
> of a VM to be encrypted with a key unique to this VM. In this way
On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini
wrote:
> xen_ulong_t is widely used in public headers.
>
> Signed-off-by: Stefano Stabellini
> ---
>
> Given that xen_ulong_t is used in public headers there could be a better
> place for documenting it but this was the most straightforward to
The goal is to use only fixed-size integers in public headers, such as
uint32_t and uint64_t.
However, there are cases where the ABI changes depending on the
architecture. In those cases, adding #ifdefs might be the clearest
solution but it is also cumbersome. We already define a xen_ulong_t type
Replace all int and long in few remaining x86-specific headers and
x86-specific hypercalls.
Signed-off-by: Stefano Stabellini
---
xen/include/public/arch-x86/hvm/save.h | 4 +-
xen/include/public/arch-x86/xen-x86_32.h | 10 ++---
xen/include/public/arch-x86/xen-x86_64.h | 10 ++---
xen_ulong_t is widely used in public headers.
Signed-off-by: Stefano Stabellini
---
Given that xen_ulong_t is used in public headers there could be a better
place for documenting it but this was the most straightforward to add.
---
docs/misra/C-language-toolchain.rst | 11 +++
1 file
Straightforward int -> int32_t and unsigned int -> uint32_t replacements
in public headers. No ABI or semantic changes intended.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- avoid changes to GUEST_HANDLEs for now (there was one GUEST_HANDLE
change in v1)
---
xen/include/public/kexec.h
Hi all,
This short patch series replaces integers without a fixed size with
fixed-size integers in public headers.
Cheers,
Stefano
Hi Juergen,
On Tue, Apr 9, 2024 at 5:47 AM Juergen Gross wrote:
>
> When running as Xen PV guest in some cases W^X violation WARN()s have
> been observed. Those WARN()s are produced by verify_rwx(), which looks
> into the PTE to verify that writable kernel pages have the NX bit set
> in order to
On Wed, 10 Apr 2024, Andrew Cooper wrote:
> Resolves 4740 MISRA R7.2 violations.
LOL!!
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: consult...@bugseng.com
> CC: Roberto Bagnara
> CC:
On Wed, 10 Apr 2024, Andrew Cooper wrote:
> Resolves an R7.2 violation.
>
> Fixes: c286bb93d20c ("xen/spinlock: support higher number of cpus")
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
On Wed, 10 Apr 2024, Andrew Cooper wrote:
> Resolves a MISRA R5.3 violation.
>
> Fixes: 622bdd962822 ("vpci/header: handle p2m range sets per BAR")
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> On 10 Apr 2024, at 19:42, Andrew Cooper wrote:
>
> All other actions it used to perform have been converted to build-time
> initialisation. The extable setup can done at build time too.
>
> This is one fewer setup step required to get exceptions working.
>
> Take the opportunity to move
On Wed, 10 Apr 2024, Andrew Cooper wrote:
> When CONFIG_SPECULATIVE_HARDEN_LOCK is active, this reads:
>
> static always_inline bool lock_evaluate_nospec(bool condition)
> {
> return arch_lock_evaluate_nospec(condition);
> return condition;
> }
>
> Insert an #else to take out
On Wed, 10 Apr 2024, Andrew Cooper wrote:
> Despite noticing an impending Rule 19.1 violation, the adjustment made (the
> uint32_t cast) wasn't sufficient to avoid it. Try again.
>
> Fixes: 6a98383b0877 ("x86/HVM: clear upper halves of GPRs upon entry from
> 32-bit code")
> Signed-off-by:
flight 185302 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185302/
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
Hi Stefano, Vikram, Viresh,
Thank you for your answers and support, and sorry for my late reply.
On 12/01/2024 02:56, Vikram Garhwal wrote:
> Hi Andrei & Stefano,
>
> Actually, QEMU patches are already upstreamed for virtio-blk and virtio-net
> devices available in v8.2.0.
> For virtio with
> On 10 Apr 2024, at 20:26, Andrew Cooper wrote:
>
> When CONFIG_SPECULATIVE_HARDEN_LOCK is active, this reads:
>
> static always_inline bool lock_evaluate_nospec(bool condition)
> {
> return arch_lock_evaluate_nospec(condition);
> return condition;
> }
>
> Insert an #else to
> On 10 Apr 2024, at 20:33, Andrew Cooper wrote:
>
> Resolves a MISRA R5.3 violation.
>
> Fixes: 622bdd962822 ("vpci/header: handle p2m range sets per BAR")
> Signed-off-by: Andrew Cooper
> ---
Reviewed-by: Luca Fancellu
> On 10 Apr 2024, at 20:35, Andrew Cooper wrote:
>
> Resolves an R7.2 violation.
>
> Fixes: c286bb93d20c ("xen/spinlock: support higher number of cpus")
> Signed-off-by: Andrew Cooper
Yes makes sense
Reviewed-by: Luca Fancellu
On Wed, Apr 10, 2024 at 3:50 PM Jason Andryuk wrote:
>
> The PVH entrypoint is 32bit non-PIC code running the uncompressed
> vmlinux at its load address CONFIG_PHYSICAL_START - default 0x100
> (16MB). The kernel is loaded at that physical address inside the VM by
> the VMM software
flight 185295 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 185278
Tests which did not
The PVH entry point will need an additional set of prebuild page tables.
Move the macros and defines to a new header so they can be re-used.
Signed-off-by: Jason Andryuk
---
checkpatch.pl gives an error: "ERROR: Macros with multiple statements
should be enclosed in a do - while loop" about the
The PVH entry point is 32bit. For a 64bit kernel, the entry point must
switch to 64bit mode, which requires a set of page tables. In the past,
PVH used init_top_pgt.
This works fine when the kernel is loaded at LOAD_PHYSICAL_ADDR, as the
page tables are prebuilt for this address. If the kernel
The PVH entrypoint is 32bit non-PIC code running the uncompressed
vmlinux at its load address CONFIG_PHYSICAL_START - default 0x100
(16MB). The kernel is loaded at that physical address inside the VM by
the VMM software (Xen/QEMU).
When running a Xen PVH Dom0, the host reserved addresses are
Sync Xen's elfnote.h header from xen.git to pull in the
XEN_ELFNOTE_PHYS32_RELOC define.
xen commit dfc9fab00378 ("x86/PVH: Support relocatable dom0 kernels")
This is a copy except for the removal of the emacs editor config at the
end of the file.
Signed-off-by: Jason Andryuk
---
Using the PVH entry point, the uncompressed vmlinux is loaded at
LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the
address in XEN_ELFNOTE_PHYS32_ENTRY, pvh_start_xen, with paging
disabled.
Loading at LOAD_PHYSICAL_ADDR has not been a problem in the past as
virtual machines don't have
phys_base needs to be set for __pa() to work in xen_pvh_init() when
finding the hypercall page. Set it before calling into
xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to
avoid __startup_64() adding to it and creating an incorrect value.
Signed-off-by: Jason Andryuk
---
Resolves 4740 MISRA R7.2 violations.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: consult...@bugseng.com
CC: Roberto Bagnara
CC: Federico Serafini
CC: Nicola Vetrini
of 4935, so 96% of them...
---
xen/arch/x86/x86_emulate/x86_emulate.h
Resolves an R7.2 violation.
Fixes: c286bb93d20c ("xen/spinlock: support higher number of cpus")
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Juergen Gross
CC: consult...@bugseng.com
CC: Roberto Bagnara
CC: Federico Serafini
Resolves a MISRA R5.3 violation.
Fixes: 622bdd962822 ("vpci/header: handle p2m range sets per BAR")
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: consult...@bugseng.com
CC: Roberto Bagnara
CC: Federico Serafini
CC: Nicola Vetrini
---
When CONFIG_SPECULATIVE_HARDEN_LOCK is active, this reads:
static always_inline bool lock_evaluate_nospec(bool condition)
{
return arch_lock_evaluate_nospec(condition);
return condition;
}
Insert an #else to take out the second return.
Fixes: 7ef0084418e1 ("x86/spinlock:
Given 3 statically initialised objects, its easy to link the list at build
time. There's no need to do it during runtime at boot (and with IRQs-off,
even).
As a consequence, register_virtual_region() can now move inside ifdef
CONFIG_LIVEPATCH like unregister_virtual_region().
Signed-off-by:
Bugframe linkage is identical in all architectures. This is not surprising
given that it is (now) only consumed by common/virtual_region.c
Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
structure.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan
All other actions it used to perform have been converted to build-time
initialisation. The extable setup can done at build time too.
This is one fewer setup step required to get exceptions working.
Take the opportunity to move 'core' into read_mostly, where it probably should
have lived all
The start/stop1/etc linkage scheme predates struct virtual_region, and as
setup_virtual_regions() shows, it's awkward to express in the new scheme.
Change the linker to provide explicit start/stop symbols for each bugframe
type, and change virtual_region to have a stop pointer rather than a
There is nothing that setup_virtual_regions() does which can't be done at
build time. Make this happen.
Importantly, this removes logic from needed prior to setting up exceptions.
v2:
* Only minor changes in patches 3 and 4.
Andrew Cooper (4):
xen/link: Introduce a common BUGFRAMES
flight 185285 xen-4.18-testing real [real]
flight 185301 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185285/
http://logs.test-lab.xenproject.org/osstest/logs/185301/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, 10 Apr 2024, Roger Pau Monné wrote:
> On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote:
> > On 10/04/2024 4:14 pm, Roger Pau Monné wrote:
> > > On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
> > >> +
> > >> +config AMD
> > >> +bool "AMD"
> > >> +
On 10/04/2024 5:34 pm, Roger Pau Monné wrote:
> On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote:
>> On 10/04/2024 4:14 pm, Roger Pau Monné wrote:
>>> On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
+
+config AMD
+ bool "AMD"
After double checking what
On Thu, Jan 04, 2024 at 12:49:58PM +0100, Jan Kara wrote:
> On Sat 23-12-23 17:31:55, Matthew Wilcox wrote:
> > On Thu, Dec 21, 2023 at 04:57:04PM +0800, Yu Kuai wrote:
> > > @@ -3674,16 +3670,17 @@ struct btrfs_super_block
> > > *btrfs_read_dev_one_super(struct block_device *bdev,
> > >
Also sent emacs ~ file. To ignore, sorry
Le mercredi 10/04/2024 17:39, Andrei Semenov a écrit :
///HERE YOU GO
Andrei Semenov (2):
Implemented AMD SEV discovery and enabling.
Implemented Amd Secure Processor device driver
xen/arch/x86/cpu/amd.c | 53 ++
On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote:
> On 10/04/2024 4:14 pm, Roger Pau Monné wrote:
> > On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
> >> +
> >> +config AMD
> >> + bool "AMD"
> >> +default y
> >> +help
> >> + Detection, tunings
flight 185284 xen-4.17-testing real [real]
flight 185298 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185284/
http://logs.test-lab.xenproject.org/osstest/logs/185298/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
RE_NOTIF_PEND_INTR:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
>> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
&
On 10/04/2024 4:14 pm, Roger Pau Monné wrote:
> On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
>> We eventually want to be able to build a stripped down Xen for a single
>> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
>> available to randconfig), and
On Wed, Apr 10, 2024 at 02:43:13PM +0300, Manos Pitsidianakis wrote:
> This patch series proposes converting the compile-time define
> LIBXL_DEVICE_MODEL_START_TIMEOUT value to an optionally overridden by
> environment variable value, just like the current behavior for
>
Hi Bertrand,
On Wed, Apr 10, 2024 at 5:41 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 10 Apr 2024, at 16:27, Jens Wiklander wrote:
> >
> > On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
> > wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
> >>>
> >>>
if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
With the recently posted kernel patch
https://lore.kernel.org/all/20240410-ffa_npi_support-v
Hi Jens,
> On 10 Apr 2024, at 16:27, Jens Wiklander wrote:
>
> On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>>>
>>> Add support for FF-A notifications, currently limited to an SP (Secure
>>> Partition)
Signed-off-by: Andrei Semenov
---
xen/arch/x86/cpu/amd.c | 53 ++
xen/arch/x86/hvm/svm/Makefile | 1 +
xen/arch/x86/hvm/svm/sev.c | 4 ++
xen/arch/x86/include/asm/cpufeature.h | 3 ++
xen/arch/x86/include/asm/cpufeatures.h | 2 +
Signed-off-by: Andrei Semenov
---
xen/arch/x86/include/asm/psp-sev.h | 655 +++
xen/drivers/Kconfig| 2 +
xen/drivers/Makefile | 1 +
xen/drivers/crypto/Kconfig | 10 +
xen/drivers/crypto/Makefile| 1 +
///HERE YOU GO
Andrei Semenov (2):
Implemented AMD SEV discovery and enabling.
Implemented Amd Secure Processor device driver
xen/arch/x86/cpu/amd.c | 53 ++
xen/arch/x86/hvm/svm/Makefile | 1 +
xen/arch/x86/hvm/svm/sev.c | 4 +
On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
> We eventually want to be able to build a stripped down Xen for a single
> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
> available to randconfig), and adjust the microcode logic.
>
> No practical
Hi Luca,
On 10/04/2024 16:08, Luca Fancellu wrote:
>
>
> Hi Michal,
>
>>>
>>> For direct-map domain with iommu on, after we get guest shm info from
>>> "kinfo",
>>> we use "remove_shm_from_rangeset" to remove static shm.
>>>
>>> For direct-map domain with iommu off, as static shm has already
Hi Jens,
> On 10 Apr 2024, at 16:27, Jens Wiklander wrote:
>
> On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>>>
>>> Add support for FF-A notifications, currently limited to an SP (Secure
>>> Partition)
On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
> >
> > Add support for FF-A notifications, currently limited to an SP (Secure
> > Partition) sending an asynchronous notification to a guest.
> >
> > Guests and Xen itself
On Fri, Apr 05, 2024 at 01:11:28PM +0100, Fouad Hilly wrote:
> diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
> index 5ecdfa2c7934..edce45bc2a17 100644
> --- a/tools/misc/xen-ucode.c
> +++ b/tools/misc/xen-ucode.c
> @@ -21,10 +23,11 @@ static const char amd_id[] =
On 10.04.24 15:48, Ingo Molnar wrote:
* Juergen Gross wrote:
When running as Xen PV guest in some cases W^X violation WARN()s have
been observed. Those WARN()s are produced by verify_rwx(), which looks
into the PTE to verify that writable kernel pages have the NX bit set
in order to avoid
Hi Michal,
>>
>> For direct-map domain with iommu off, as static shm has already been taken
>> care of through reserved memory banks, we do nothing.
> Stale info given that shmem is no longer part of reserved memory banks. It's
> been taken care
> of by removing shmem regions in
Hi Michal,
>>
>> For direct-map domain with iommu on, after we get guest shm info from
>> "kinfo",
>> we use "remove_shm_from_rangeset" to remove static shm.
>>
>> For direct-map domain with iommu off, as static shm has already been taken
>> care of through reserved memory banks, we do
On Tue, Apr 09, 2024 at 12:13:23PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 09, 2024 at 11:32:07AM +0100, Ross Lagerwall wrote:
> > Remove Konrad from the livepatch maintainers list as he hasn't been
> > active for a few years.
> > At the same time, add Roger as a new maintainer since he
On Fri, Apr 05, 2024 at 01:11:27PM +0100, Fouad Hilly wrote:
> diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> index 1edcebfb9f9c..9bde991c5df5 100644
> --- a/tools/misc/xen-ucode.c
> +++ b/tools/misc/xen-ucode.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
* Juergen Gross wrote:
> When running as Xen PV guest in some cases W^X violation WARN()s have
> been observed. Those WARN()s are produced by verify_rwx(), which looks
> into the PTE to verify that writable kernel pages have the NX bit set
> in order to avoid code modifications of the kernel
Hi Jens,
On 09/04/2024 17:36, Jens Wiklander wrote:
>
>
> Updates so request_irq() can be used with a dynamically assigned SGI irq
> as input.
At this point it would be handy to mention the use case for which you need to
add this support
>
> gic_route_irq_to_xen() don't gic_set_irq_type()
On 10/04/2024 11:37 am, Andrew Cooper wrote:
> Despite noticing an impending Rule 19.1 violation, the adjustment made (the
> uint32_t cast) wasn't sufficient to avoid it. Try again.
>
> Fixes: 6a98383b0877 ("x86/HVM: clear upper halves of GPRs upon entry from
> 32-bit code")
> Signed-off-by:
When debugging QEMU, the need to run it under Valgrind and asan meant
the compile-time define LIBXL_DEVICE_MODEL_START_TIMEOUT must be changed
to allow for `xl` to wait longer while the instrumented QEMU
initializes.
This commit adds support for reading the environment variable
Various timeout values that depend on the device model should also
respect the device model start timeout setting. This commit adds the
__libxl_device_model_start_timeout() value to those time outs without
changing their default values.
Signed-off-by: Manos Pitsidianakis
---
This patch series proposes converting the compile-time define
LIBXL_DEVICE_MODEL_START_TIMEOUT value to an optionally overridden by
environment variable value, just like the current behavior for
LIBXL_BOOTLOADER_TIMEOUT is.
Manos Pitsidianakis (2):
libs/light: add device model start timeout
On 10/04/2024 13:19, Luca Fancellu wrote:
>
>
>
> Afterwards, create a new structure 'struct shared_meminfo' which
> has the same interface of 'struct meminfo', but requires less
I would expect some justification for selecting 32 as the max number of
shmem banks
>>>
>>>
Afterwards, create a new structure 'struct shared_meminfo' which
has the same interface of 'struct meminfo', but requires less
>>> I would expect some justification for selecting 32 as the max number of
>>> shmem banks
>>
>> So I have to say I picked up a value I thought was ok
Hi Luca,
On 09/04/2024 13:45, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> Static shared memory acts as reserved memory in guest, so it shall be
> excluded from extended regions.
>
> Extended regions are taken care of under three different scenarios:
> normal DomU, direct-map domain with
On Fri, Mar 1, 2024 at 6:08 PM Alex Bennée wrote:
> Vikram Garhwal writes:
>
> > From: Juergen Gross
> >
> > Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
> > case it can't find a matching entry for a pointer value. Both cases
> > are bad, so change that to return an
On Fri, Mar 1, 2024 at 3:06 PM Alex Bennée wrote:
> Vikram Garhwal writes:
>
> > From: Juergen Gross
> >
> > Add a memory region which can be used to automatically map granted
> > memory. It is starting at 0x8000ULL in order to be able to
> > distinguish it from normal RAM.
>
> Is
On Fri, Mar 1, 2024 at 12:34 AM Stefano Stabellini
wrote:
> On Tue, 27 Feb 2024, Vikram Garhwal wrote:
> > From: Juergen Gross
> >
> > Add the callbacks for mapping/unmapping guest memory via grants to the
> > special grant memory region.
> >
> > Signed-off-by: Juergen Gross
> > Signed-off-by:
On 10/04/2024 12:56, Luca Fancellu wrote:
>
>
> Hi Michal,
>
>> On 10 Apr 2024, at 11:01, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 09/04/2024 13:45, Luca Fancellu wrote:
>>>
>>>
>>> Currently the memory footprint of the static shared memory feature
>>> is impacting all the struct meminfo
Hi Michal,
> On 10 Apr 2024, at 11:01, Michal Orzel wrote:
>
> Hi Luca,
>
> On 09/04/2024 13:45, Luca Fancellu wrote:
>>
>>
>> Currently the memory footprint of the static shared memory feature
>> is impacting all the struct meminfo instances with memory space
>> that is not going to be
Despite noticing an impending Rule 19.1 violation, the adjustment made (the
uint32_t cast) wasn't sufficient to avoid it. Try again.
Fixes: 6a98383b0877 ("x86/HVM: clear upper halves of GPRs upon entry from
32-bit code")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
On Wed, Apr 10, 2024 at 12:21 PM Andrew Cooper
wrote:
> On 10/04/2024 10:19 am, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Use the generic xen/linkage.h macros when annotating symbols.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> > xen/arch/arm/arm64/entry.S | 12
On 10/04/2024 10:19 am, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Use the generic xen/linkage.h macros when annotating symbols.
>
> Signed-off-by: Edgar E. Iglesias
> ---
> xen/arch/arm/arm64/entry.S | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff
Hi Luca,
On 09/04/2024 13:45, Luca Fancellu wrote:
>
>
> Currently the memory footprint of the static shared memory feature
> is impacting all the struct meminfo instances with memory space
> that is not going to be used.
>
> To solve this issue, rework the static shared memory extra
>
On Mon, Apr 8, 2024 at 11:42 AM Jan Beulich wrote:
>
> On 28.03.2024 16:11, Ross Lagerwall wrote:
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -3,6 +3,7 @@
> > * is intended to be included by common/efi/boot.c _only_, and
> > * therefore can define arch
flight 185283 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185283/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-qcow2 19 guest-start/debian.repeat fail baseline
untested
test-armhf-armhf-libvirt
On Mon, Apr 8, 2024 at 11:25 AM Jan Beulich wrote:
>
> On 28.03.2024 16:11, Ross Lagerwall wrote:
> > In addition to building xen.efi and xen.gz, build xen-mbi.exe. The
> > latter is a PE binary that can be used with a multiboot2 loader that
> > supports loading PE binaries.
>
> I have to admit I
From: "Edgar E. Iglesias"
On the way towards Xen safety certification we're evaluating the use
of tools to collect code-coverage/profiling information from execution
traces. Some tools rely on ELF symbols for code being declared with
type FUNC and having a symbol size.
We currently annotate
From: "Edgar E. Iglesias"
Add missing code symbol annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/entry.S | 60 ++
1 file changed, 42 insertions(+), 18 deletions(-)
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros when annotating symbols.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/entry.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
Hi Jens,
> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>
> Add support for FF-A notifications, currently limited to an SP (Secure
> Partition) sending an asynchronous notification to a guest.
>
> Guests and Xen itself are made aware of pending notifications with an
> interrupt. The
Hi Luca,
On 09/04/2024 13:45, Luca Fancellu wrote:
>
>
> The function check_reserved_regions_overlap is calling
> 'meminfo_overlap_check' on the same type of structure, this code
> can be written in a way to avoid code duplication, so rework the
> function to do that.
>
> Signed-off-by: Luca
Hi Jens,
> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>
> Simplify ffa_handle_mem_share() by removing the start_page_idx and
> last_page_idx parameters from get_shm_pages() and check that the number
> of pages matches expectations at the end of get_shm_pages().
>
> Signed-off-by: Jens
Hi Jens,
> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>
> Replace read_atomic() with ACCESS_ONCE() to match the intended use, that
> is, to prevent the compiler from (via optimization) reading shared
> memory more than once.
This definitely makes sense.
>
> Signed-off-by: Jens Wiklander
Hi John,
On 10/04/2024 08:53, John Ernberg wrote:
>
>
> On 4/9/24 8:47 AM, Michal Orzel wrote:
>> Hi John,
>>
>> On 08/04/2024 18:11, John Ernberg wrote:
>>>
>>>
>>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>>> SIP calls into the firmware to enable certain
Hi Jens,
> On 9 Apr 2024, at 17:36, Jens Wiklander wrote:
>
> Refactors the large switch block in ffa_handle_call() to use common code
> for the simple case where it's either an error code or success with no
> further parameters.
>
> Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand
On 4/9/24 8:47 AM, Michal Orzel wrote:
> Hi John,
>
> On 08/04/2024 18:11, John Ernberg wrote:
>>
>>
>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>>
>> Provide a basic platform
97 matches
Mail list logo
