On 2/22/21 11:16 PM, Jan Beulich wrote:
> It is on my list of things to look at. While probably not a good excuse,
> my looking at previous versions of this makes we somewhat hesitant to
> open any of these patch mails ... But I mean to get to it.
>
> Jan
>
Thanks for this response. I did comb
On 2/23/21 1:04 AM, Roger Pau Monné wrote:
> On Thu, Jan 21, 2021 at 04:51:43PM -0800, Bobby Eshleman wrote:
>> From: Daniel Kiper
>>
>> In comparison to ELF the PE format is not supported by the Multiboot2
>> protocol. So, if we wish to load xen.mb.efi using this protocol we have
>> to add MULTIB
On 2/25/21 7:24 AM, Connor Davis wrote:
> Return from cpu_schedule_up when either cpu is 0 or
> NR_CPUS == 1. This fixes the following:
>
> core.c: In function 'cpu_schedule_up':
> core.c:2769:19: error: array subscript 1 is above array bounds
> of 'struct vcpu *[1]' [-Werror=array-bounds]
> 2769
Hey Anthony,
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8a52a03969fe..03a5553116a8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> -F: xen/include/asm-arm/
> +F: xen/include/arch-arm/
... snip ...
> -F: xen/include/asm-x86/
> +F: xen/include/arch-x86/
It looks like riscv will al
ot;tests" "all" and "build" target are removed.
> "subtree-force-update" target isn't useful so it is removed as well.
>
> test/livepatch/Makefile doesn't need default target anymore, Rules.mk
> will build everything in $(extra-y) and thus all *.livepatch.
>
> Signed-off-by: Anthony PERARD
Acked-by: Bob Eshleman
Thanks,
Bobby
100644
> index ..15a4a65f6615
> --- /dev/null
> +++ b/xen/arch/riscv/riscv64/Makefile
> @@ -0,0 +1 @@
> +extra-y += head.o
>
Acked-by: Bob Eshleman
--
Bobby Eshleman
SE at Vates SAS
On 7/14/21 2:34 AM, Jan Beulich wrote:
>
> ... we strive to have new insertions be sorted alphabetically. When
> the existing section to insert into isn't suitably sorted yet, what
> I normally do is try to find a place where at least the immediately
> adjacent neighbors then fit the sorting goal.
Jan,
I mulled over your feedback and I think I can now see your reservations
with this series.
I'm wondering if the long-term goal of using the xen mb1/mb2 binary as the
basis for creating a EFI loadable mb1/mb2 payload is actually the wrong
approach.
After all, I do not see a feasible way to ma
On 5/14/21 11:53 AM, Connor Davis wrote:
> +
> +# There is a regression in GDB that causes an assertion error
> +# when setting breakpoints, use this commit until it is fixed!
> +RUN git clone --recursive -j$(nproc) --progress
> https://github.com/riscv/riscv-gnu-toolchain && \
> +cd riscv-gnu
On 5/14/21 11:53 AM, Connor Davis wrote:
> Add arch-specific makefiles and configs needed to build for
> riscv64. Also add a minimal head.S that is a simple infinite loop.
> head.o can be built with
>
> $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen TARGET=head.o
>
I recently realized that
On 5/14/21 4:47 PM, Connor Davis wrote:
>
> On 5/14/21 3:53 PM, Bob Eshleman wrote:
>> On 5/14/21 11:53 AM, Connor Davis wrote:
>>
>>> +
>>> +#ifdef CONFIG_RISCV_64
>>> +
>>> +/*
>>> + * RISC-V Layout:
>>&g
On 5/25/21 1:48 AM, Jan Beulich wrote:
> On 24.05.2021 16:34, Connor Davis wrote:
>> Add arch-specific makefiles and configs needed to build for
>> riscv. Also add a minimal head.S that is a simple infinite loop.
>> head.o can be built with
>>
>> $ make XEN_TARGET_ARCH=riscv SUBSYSTEMS=xen -C xen t
g.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d46b08a0d2..5a1f92422a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -456,6 +456,15 @@ F: tools/libs/light/libxl_nonetbuffer.c
> F: tools/hotplug/Linux/remus-netbuf-setup
> F: tools/hotplug/Linux/block-drbd-
On 2/25/21 7:01 PM, Connor Davis wrote:
> On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote:
>> riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0
>>
>> Which version of GCC are you seeing emit this?
>
> The one from cloned from github.com/riscv/riscv-gnu-toolchai
On 2/25/21 3:14 PM, Andrew Cooper wrote:
>
> Well - this is orders of magnitude more complicated than it ought to
> be. An empty head.S doesn't (well - shouldn't) need the overwhelming
> majority of this.
>
> Do you know how all of this is being pulled in? Is it from attempting
> to compile com
On 2/25/21 7:23 AM, Connor Davis wrote:
> Hi all,
>
> This series introduces a minimal build for RISCV. It is based on Bobby's
> previous work from last year[0]. I have worked to rebase onto current Xen,
> as well as update the various header files borrowed from Linux.
>
> This series provides th
>> On 2/25/21 3:14 PM, Andrew Cooper wrote:
>>
>> It sounds like you'd prefer no common to start and none of the
>> arch_* calls it relies on?
>
> We definitely want "stuff compiled under RISC-V" to be caught in CI, but
> that doesn't mean "wedge all of common in with stubs to begin with".
>
> Ho
On 3/10/21 1:29 AM, Gurrieri Stefano wrote:
> Hello,
>
> I'm working on the platform STM32MP1 based on cortex-A7 dual core. This is an
> armv7-A that has the "Hardware virtualization support".
> My current Linux BSP is built using Yocto Project... but now, I'm asking how
> to enable XEN on my pl
Hey all,
We would like to start a working group for secure boot support in Xen
to coordinate the various interested parties and set out a plan for
the feature and its implications for the whole Xen system.
The end goal is a full implementation that restricts the interfaces
dom0 has to affect Xen,
Awesome, it's great to see this interest.
I'll wait until early next week to give more
people a chance to pitch in, then start
bugging everybody about availability to
schedule a meeting. I'll put together a
small agenda then to get the ball rolling.
Thanks all.
Hey everyone,
I think most who are interested have acked the thread at
this point and I've CC'd everyone (please add anyone if
I've missed them).
I'd like to suggest we have a first group call to
set out an agenda, define scope, and start identifying
the direction the project would like to go for
On 3/16/21 1:07 PM, Roman Shaposhnik wrote:
> WFIW: all 3 time slots work for me.
>
> Looking forward to this!
>
> Thanks,
> Roman.
>
Thanks Roman, same here!
--
Bobby Eshleman
SE at Vates SAS
Hey all,
It looks like the following date works best:
Mon. March 29th, 16:00 UTC
The meeting place URL:
https://meet.vates.fr/xen-lockdown
Feel free to let us know if the time presents a conflict.
--
Bobby Eshleman
SE at Vates SAS
Hey all,
I just wanted to send this out as a new email thread in case
anyone missed the reply on the previous thread.
It looks like the following date works best:
Mon. March 29th, 16:00 UTC
https://meet.vates.fr/xen-lockdown
Feel free to let us know if the time presents a conflict.
--
Bobby E
# Xen Secure Boot and Lockdown
This document summarizes the Xen Secure Boot and Lockdown WG meeting that
occurred on Mon, March 29, 2021.
We identified a list of requirements for locking down a Xen system that
(at least) requires the following:
## Verified Boot Chain
Various projects are underw
25 matches
Mail list logo
