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.
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
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
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
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 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
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/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 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
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
# 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
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
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
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 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
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 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,
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
>> 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 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:
>
> 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: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 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
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/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
25 matches
Mail list logo
