Unable to decode instruction
The Rn == Rt warning is only applicable to single register load/stores
so add some verification steps before to weed out unexpected accesses.
While at it update the Arm ARM references to the latest version of the
documentation.
Signed-off-by: Alex Bennée
Cc: Manos
When device_model_args is set we almost certainly want to spawn the
device model. This is most useful when debugging with QEMU and you
want to specify a new device type for testing without teaching libxl
about the device itself.
Signed-off-by: Alex Bennée
---
This is very much an RFC, it's
trace_xen_ram_addr_from_mapcache_found(reventry->paddr_index,
> - reventry->vaddr_req);
> -}
If these tracepoints aren't useful they need removing from trace-events.
However I suspect it would be better to keep them
ere? I couldn't
find anything googling or on the Xen wiki. I'm guessing this is going to
be shared across all 64 bit HVM arches in Xen?
Anyway:
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Julien Grall writes:
> Hi Alex,
>
> On 31/01/2024 17:50, Alex Bennée wrote:
>> While debugging VirtIO on Arm we ran into a warning due to memory
>> being memcpy'd across MMIO space. While the bug was in the mappings
>> the warning was a little confusing:
>>(
section
numbers.
Signed-off-by: Alex Bennée
Cc: Manos Pitsidianakis
---
xen/arch/arm/decode.c | 20
xen/arch/arm/decode.h | 38 +++---
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
urrent monitor or stderr), and in
>> a uniform format.
>> Use error_printf() & friends to print additional information.
>
> This commit changes fprintfs that report warnings and errors to the
> appropriate report functions.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Sig
e that are used for tracing
> into tracepoints.
>
> Signed-off-by: Manos Pitsidianakis
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
e that are used for tracing
> into tracepoints.
>
> Signed-off-by: Manos Pitsidianakis
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Huang Rui writes:
> Configure a new feature flag (context_create_with_flags) for
> virglrenderer.
>
> Originally-by: Antonio Caggiano
> Signed-off-by: Huang Rui
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Alex Bennée writes:
> Huang Rui writes:
>
>> From: Robert Beckett
>>
>> This relies on a virglrenderer change to include the dmabuf fd when
>> returning resource info.
>>
>
>> +static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
>
t virgl_renderer_resource_info {
351:pub struct virgl_renderer_resource_info_ext {
353: pub base: virgl_renderer_resource_info,
359:impl Default for virgl_renderer_resource_info_ext {
373:info: *mut virgl_renderer_resource_info,
379:info: *mut virgl_renderer_resource_info_ext,
Which makes me think a) its picked up the older virgl headers and b) the
crosvm/rutabaf_gfx install needs a fix.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
part of the historical baggage of
x86 - really it's just a xenpv-irq controller?
Anyway yeah I think just move it from hw/i386/xen to hw/xen and maybe
give it a new name with an alias to the old one we can deprecate over
time?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
e avoided
is to have a "static global" in the main .c file for the module and then
provide a helper access function for other files to read it. That also
makes re-factoring easier if things like locking need to be added down
the line.
We still do have a few true global variables which need "extern"
declarations in the headers but if we can avoid adding more that would
be good.
Of course ideally this sort of data would be wrapped up in QOM
structures but I can see the argument for the host domain ID.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
verview document in our
manual for how Xen guests are supported under KVM?
>-append "loglvl=all -- console=hvc0 root=/dev/xvda1"
>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
ing
>> links, or responding to this email.
>>
>>
>> On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote:
>>>
>>> Peter Maydell writes:
>>>
>>>> On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini
>>>> wrote:
>>>>> As Xen is
unsigned long curr = (unsigned long)current;
return atomic_long_try_cmpxchg_release(>owner, , 0UL);
}
so you should already have completed your writes by that point.
>
>> In general, shouldn't the state be checked and modified in the locked area?
>
> The handler runs separately for each vcpu and shouldn't run in parallel for
> the
> same vcpu. And so only one thread should ever be accessing ioreq port
> structure.
>
> The lock is there to protect the ioeventfds list (as mentioned in struct
> declaration) against parallel access, as threads for different vcpus may end
> up
> accessing it simultaneously.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Jan Beulich writes:
> On 11.09.2023 17:26, Alex Bennée wrote:
>> Jan Beulich writes:
>>> On 02.09.2023 17:11, Javi Merino wrote:
>>>> --- a/xen/common/coverage/Makefile
>>>> +++ b/xen/common/coverage/Makefile
>>>>
>> #endif
>>
>> #define GCOV_COUNTERS 9
>> +#define GCOV_UNIT_SIZE 1
>>
>> #include "gcc_4_7.c"
>>
>> --- a/xen/common/coverage/gcc_5.c
>> +++ b/xen/common/coverage/gcc_5.c
>> @@ -19,6 +19,7 @@
>> #endif
>>
>> #define GCOV_COUNTERS 10
>> +#define GCOV_UNIT_SIZE 1
>>
>> #include "gcc_4_7.c"
>>
>
> ... touching these two files could be avoided altogether.
>
> Henry - afaict this was submitted after the feature submission deadline,
> so you may want to consider giving it an exception.
>
> Jan
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Ayan Kumar Halder writes:
> Hi Peter/Alex,
>
> Appreciate your help. :)
>
> On 31/08/2023 11:03, Peter Maydell wrote:
>> On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote:
>>>
>>> Peter Maydell writes:
>>>
>>>> On Thu, 31 Aug
Peter Maydell writes:
> On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote:
>>
>>
>> Peter Maydell writes:
>>
>> > On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini
>> > wrote:
>> >> As Xen is gaining R52 and R82 support, it wo
there is a lot
of other stuff needed specifically for RME including what we do about
modelling things like TDISP. Realistically it will be awhile before we
get to completing all of that.
>
> thanks
> -- PMM
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
ther feedback on how QEMU could be improved to help the Xen
community deliver it's roadmap faster.
Thank you for your time and I look forward to any feedback :-)
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Fabiano Rosas writes:
> Vikram Garhwal writes:
>
>> Add CONFIG_XEN for aarch64 device to support build for ARM targets.
>>
>> Signed-off-by: Vikram Garhwal
>> Signed-off-by: Stefano Stabellini
>> Reviewed-by: Alex Bennée
>> ---
>> meson.bu
s builds qemu-system-i386, but with your changes and the
work Fabiano is doing:
Message-Id: <20230313151058.19645-1-faro...@suse.de>
Date: Mon, 13 Mar 2023 12:10:48 -0300
Subject: [PATCH v9 00/10] target/arm: Allow CONFIG_TCG=n builds
From: Fabiano Rosas
We should be able to have a qemu-system-aarch64 supporting Xen without TCG
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
fail to allocate the vCPU context its game over anyway any
established QEMU practice is its ok to assert fail on a malloc when
there isn't enough memory. IOW keep the g_malloc0 and remove the error
handling case.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
"Michael S. Tsirkin" writes:
> On Wed, Apr 05, 2023 at 11:00:34AM +0100, Alex Bennée wrote:
>>
>> Viresh Kumar writes:
>>
>> > On 09-03-23, 14:20, Viresh Kumar wrote:
>> >> Hello,
>> >>
>> >> This patchs
er-device series so I'll get merged
with that series unless mst wants to take it now.
>
> Thanks.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
eature is negotiated, the front-end will send the additional
> information within the memory regions themselves.
>
> Signed-off-by: Viresh Kumar
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
While at it, also rename "memory regions description" to "multiple
> memory regions description", to avoid potential confusion around similar
> names. And define single region before multiple ones.
>
> This is just a documentation optimization, the protocol remains the sa
de...@nongnu.org, virtio-...@lists.oasis-open.org, "Michael S.
> Tsirkin" , Vincent Guittot ,
> Alex Bennée ,
> stratos-...@op-lists.linaro.org, Oleksandr Tyshchenko
> , xen-de...@lists.xen.org, Andrew Cooper
> , Juergen Gross , Sebastien
> Boeuf
> , Liu Jia
gt; + any memory-regions are sent to the back-end via
> ``VHOST_USER_SET_MEM_TABLE``
> + or ``VHOST_USER_ADD_MEM_REG`` message types.
> +
>
> Back-end message types
> --
This looks good enough for me. We will see how it works in prototype.
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Philippe Mathieu-Daudé writes:
> Unused since introduction in commit 04b0de0ee8
> ("xen: factor out common functions").
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
QEMU built per domain.
I agree if this is something that can change it needs to be configured
from the command line or somehow otherwise gleaned from the source of
truth. Isn't this information available via XenStore? Isn't that what
Viresh has to do for all the VirtIO devices he's adding to libxl?
A default value for the option could be done I guess.
>
> How is that scalable?
>
> Cheers,
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
letions(-)
> create mode 100644 hw/arm/xen_arm.c
> create mode 100644 hw/xen/xen-hvm-common.c
> rename hw/{i386 => }/xen/xen-mapcache.c (100%)
> create mode 100644 include/hw/arm/xen_arch_hvm.h
> create mode 100644 include/hw/i386/xen_arch_hvm.h
> create mode 100644 include/hw/xen/arch_hvm.h
> create mode 100644 include/hw/xen/xen-hvm-common.h
--
Alex Bennée
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-mapcache.c.o
[2083/3246] Compiling C object
libqemu-aarch64-softmmu.fa.p/hw_xen_xen-hvm-common.c.o
ninja: build stopped: subcommand failed.
make: *** [Makefile:165: run-ninja] Error 1
> +
> +DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
> +#endif
> +}
If there is a minimum required version for TPM then it needs to be
picked up by configure.
--
Alex Bennée
,
> +};
> +
> +static void xen_arm_machine_register_types(void)
> +{
> +type_register_static(_arm_machine_type);
> +}
> +
> +type_init(xen_arm_machine_register_types)
> diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
> new file mode 100644
> index 00..8fd645e723
> --- /dev/null
> +++ b/include/hw/arm/xen_arch_hvm.h
> @@ -0,0 +1,9 @@
> +#ifndef HW_XEN_ARCH_ARM_HVM_H
> +#define HW_XEN_ARCH_ARM_HVM_H
> +
> +#include
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> +void arch_xen_set_memory(XenIOState *state,
> + MemoryRegionSection *section,
> + bool add);
> +#endif
> diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
> index 26674648d8..c7c515220d 100644
> --- a/include/hw/xen/arch_hvm.h
> +++ b/include/hw/xen/arch_hvm.h
> @@ -1,3 +1,5 @@
> #if defined(TARGET_I386) || defined(TARGET_X86_64)
> #include "hw/i386/xen_arch_hvm.h"
> +#elif defined(TARGET_ARM) || defined(TARGET_ARM_64)
> +#include "hw/arm/xen_arch_hvm.h"
> #endif
--
Alex Bennée
CI system:
https://gitlab.com/stsquad/qemu/-/pipelines/677956972/failures
>
>
>
> Regards,
>
> Vikram
>
>
>
> From: Alex Bennée
> Date: Thursday, October 27, 2022 at 2:24 AM
> To: Garhwal, Vikram
> Cc: qemu-de...@nongnu.org , Stabellini, Stefano
> , St
; void xen_register_framebuffer(struct MemoryRegion *mr);
> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
>
> #endif /* QEMU_HW_XEN_H */
--
Alex Bennée
squash the patches for the final version? We don't
want to intentionally break bisection.
Otherwise:
Reviewed-by: Alex Bennée
--
Alex Bennée
are only used on x86, especially the ones
> related to dirty logging.
> Updated XenIOState can be used for both aarch64 and x86.
>
> Also, remove free_phys_offset as it was unused.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Vikram Garhwal
Reviewed-by: Alex Bennée
--
Alex Bennée
> QLIST_INIT(>dev_list);
> device_listener_register(>device_listener);
>
> +no_ioreq:
> xen_bus_init();
>
> /* Initialize backend core & drivers */
--
Alex Bennée
h undeclared identifier is reported
only once for each function it appears in
--
Alex Bennée
'accel=xen' to select a Xen layout.
I don't think you can re-use the machine name and select by accelerator
because the virt machine does quite a lot of other stuff this model
doesn't support. However I've been calling this concept "xen-virt" or
maybe the explicit "xen-virtio" because that is what it is targeting.
--
Alex Bennée
sable-xen-pci-passthrough' '--cross-prefix=aarch64-linux-gnu-'
'--skip-meson'
which makes me wonder if this is a configure failure or a confusion
about being able to have host swtpm implementations during emulation but
needing target tpm for Xen?
--
Alex Bennée
Vikram Garhwal writes:
> Build fails when have_xen_pci_passthrough is disabled. This is because of
> incorrect build configuration for xen_pt_stub.c.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Vikram Garhwal
Reviewed-by: Alex Bennée
--
Alex Bennée
umentation/Networking
https://wiki.qemu.org/Documentation/Networking/NAT
that might be worth sanitising and transcribing into a section of the
system emulation manual. We can then point to :ref:`networking` in the
options documentation so the user doesn't have to piece together
disparate bits of online information themselves.
--
Alex Bennée
-144,7 +145,7 @@ int __init compute_hash_shift(struct nod
> {
> int shift;
>
> -shift = extract_lsb_from_nodes(nodes, numnodes);
> + shift = extract_lsb_from_nodes(nodes, numnodes, nodeids);
> if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
> memnodemap = _memnodemap;
> else if ( allocate_cachealigned_memnodemap() )
--
Alex Bennée
Juergen Gross writes:
> [[PGP Signed Part:Undecided]]
> On 24.08.22 17:58, Alex Bennée wrote:
>> Juergen Gross writes:
>>
>>> [[PGP Signed Part:Undecided]]
>>> On 24.08.22 13:22, Alex Bennée wrote:
>>>> Andrew Cooper writes:
>>>>
Juergen Gross writes:
> [[PGP Signed Part:Undecided]]
> On 24.08.22 13:22, Alex Bennée wrote:
>> Andrew Cooper writes:
>>
>>> On 24/08/2022 10:19, Viresh Kumar wrote:
>>>> On 24-03-22, 06:12, Juergen Gross wrote:
>>>>> For a rather long t
the hypercall buffers with the memory
> you want to map via the hypercall. At least the reference to kernel
> memory above is suggesting that.
Aren't the hypercall buffers all internal to the kernel/hypervisor
interface or are you talking about the ioctl contents?
>
>
> Juergen
>
> [2. OpenPGP public key --- application/pgp-keys;
> OpenPGP_0xB0DE9DD628BF132F.asc]...
>
> [[End of PGP Signed Part]]
--
Alex Bennée
rspace with
standard userspace API to access the guests memory. Perhaps messing
around with the semantics of the /dev/xen/[hypercall|privcmd] devices
nodes is too confusing.
Maybe we could instead:
1. Have the Xen aware VMM ask to make the guests memory visible to the
host kernels address space.
2.
Julien Grall writes:
> Hi Alex,
>
> On 10/05/2022 15:47, Alex Bennée wrote:
>> Julien Grall writes:
>>> On 10/05/2022 15:03, Alex Bennée wrote:
>>>> Julien Grall writes:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>&
Julien Grall writes:
> Hi Alex,
>
> On 10/05/2022 15:03, Alex Bennée wrote:
>> Julien Grall writes:
>>
>>> Hi Alex,
>>>
>>> On 28/04/2022 11:34, Alex Bennée wrote:
>>>> When we introduced FEAT_LPA to QEMU's -cpu max we discov
Julien Grall writes:
> Hi Alex,
>
> On 28/04/2022 11:34, Alex Bennée wrote:
>> When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
>> kernels had a bug where the physical address was copied directly from
>> ID_AA64MMFR0_EL1.PARange field. The early c
the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.
Signed-off-by: Alex Bennée
Cc: Richard Henderson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Volodymyr Babchuk
Cc: Bertrand Marquis
---
v2
- clamp p2m_ipa_bits =
the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.
Signed-off-by: Alex Bennée
Cc: Richard Henderson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Volodymyr Babchuk
Cc: Bertrand Marquis
---
xen/arch/arm/arm64/head.S | 6 +
he hypervisor itself. At some point we
would like to fix that wrinkle so we can remove the (minor) hack in
rust-vmm's mmap code to be truly hypervisor agnostic.
Anyway I hope you and your team are safe and well.
--
Alex Bennée
need to replace libxen-sys with the
>> > pure Rust implementation. Those libraries (xendevicemodel, xenevtchn,
>> > xenforeignmemory) are very stable and battle tested. Their interfaces
>> > are stable.
>>
>> Very easy. The library APIs are mess even if they are technically
>> stable, and violate various commonly-agreed rules of being a libary such
>> as not messing with stdout/stderr behind the applications back, and
>> everything gets more simple when you remove an unnecessary level of C
>> indirection.
>
> You don't have to use the stdio logger FWIW. I don't disagree things can
> be simpler though.
Not directly related to this use case but the Rust API can also be
built to make direct HYP calls which will be useful for building Rust
based unikernels that need to interact with Xen. For example for a
dom0less system running a very minimal heartbeat/healthcheck monitor
written in pure rust.
We would also like to explore unikernel virtio backends but I suspect
currently the rest of the rust-vmm virtio bits assume a degree of POSIX
like userspace to set things up.
--
Alex Bennée
es in this range available to the child after
a fork(2). This is useful to prevent copy-on-write semantics
from changing the physical location of a page if the parent
writes to it after a fork(2). (Such page relocations cause
problems for hardware that DMAs into the page.)
For the vhost-user work we need to be able to share the guest memory
between the xen-vhost-master (which is doing the ioctls to talk to Xen)
and the vhost-user daemon (which doesn't know about hypervisors but just
deals in memory and events).
Would it be enough to loosen the API and just have xen_remap_pfn()
verify the kernels VM flags are appropriately set before requesting Xen
updates the page tables?
--
Alex Bennée
Markus Armbruster writes:
> Philippe Mathieu-Daudé writes:
>
>> On 15/3/22 14:59, Markus Armbruster wrote:
>>> Alex Bennée writes:
>>>
>>>> Markus Armbruster writes:
>>>>
>>>>> g_new(T, n) is neater than g_malloc(size
ray of *char:
../semihosting/config.c:101:17: error: assignment to ‘const char **’ from
incompatible pointer type ‘void **’ [-Werror=incompatible-pointer-types]
101 | s->argv = g_renew(void *, s->argv, s->argc + 1);
| ^
cc1: all warnings being treated as errors
So it did the job of type checking but failed to build ;-)
--
Alex Bennée
> qatomic_set(>ring_state->cons_head, 0);
> */
> ring->npages = npages;
> -ring->pages = g_malloc0(npages * sizeof(void *));
> +ring->pages = g_new0(void *, npages);
At least here ring->pages agrees about void ** being the result.
So other than my queries about the sizeof(foo *) which I'd like someone
to assuage me of my concerns it looks like the script has done a
thorough mechanical job as all good scripts should ;-)
Reviewed-by: Alex Bennée
--
Alex Bennée
rmless, because QppEntry is larger than QpfEntry. Fix to allocate a
> QpfEntry instead.
>
> Cc: Greg Kurz
> Cc: Christian Schoenebeck
> Signed-off-by: Markus Armbruster
Reviewed-by: Alex Bennée
--
Alex Bennée
Markus Armbruster writes:
> This is the semantic patch from commit b45c03f585 "arm: Use g_new() &
> friends where that makes obvious sense".
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Alex Bennée
--
Alex Bennée
t launching your guests with the xl commands?
>
> So my question is, am I using the right qemu command? Anything else is needed
> to set/config?
> Note, if I didn't specify the option ' -xen-domid 4 -machine xenfv ', I can
> start qemu successfully
>
> Would you please help with it?
--
Alex Bennée
Stefano Stabellini writes:
> On Mon, 7 Feb 2022, Alex Bennée wrote:
>> Hi Stefano,
>>
>> Vincent gave an update on his virtio-scmi work at the last Stratos sync
>> call and the discussion moved onto next steps.
>
> Hi Alex,
>
> I don't know the speci
this email captures
what was missed:
https://linaro.atlassian.net/wiki/spaces/STR/pages/28682518685/2022-02-03+Project+Stratos+Sync+Meeting+Notes
Vincent, anything to add?
--
Alex Bennée
Anthony PERARD writes:
> On Thu, Nov 04, 2021 at 03:49:36PM +0000, Alex Bennée wrote:
>>
>> Anthony PERARD writes:
>>
>> > Patch series available in this git branch:
>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenbits.xen.
Alex Bennée writes:
> Anthony PERARD writes:
>
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>> br.build-system-xen-v7
>>
>> v7:
>> Out-of-tree build!
>>
>>
t; you describe the
Linux kernel style which works well where the config can be done after
the fact but I wonder if the configure approach is better suited to
something that needs a bunch of checks running. Is the configure script
pure autoconf? This should work out of the box IIRC.
--
Alex Bennée
Marek Marczykowski-Górecki writes:
> [[PGP Signed Part:Undecided]]
> On Fri, Sep 24, 2021 at 05:02:46PM +0100, Alex Bennée wrote:
>> Hi,
>
> Hi,
>
>> 2.1 Stable ABI for foreignmemory m
Alex Bennée
━━━
Table of Contents
─
1. Xen Rust Bindings ([STR-51])
.. 1. Upstream an "official" rust crate for Xen ([STR-52])
.. 2. Basic Hypervisor Interactions hypercalls ([STR-53])
.. 3. [#10] Access to XenSto
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Mon, 2021-09-13 at 13:44 +0100, Alex Bennée wrote:
>> Hi,
>>
>> As we consider the next cycle for Project Stratos I would like to make
>> some more progress on hypervisor agnosticism for our vir
Andrew Cooper writes:
> On 13/09/2021 13:44, Alex Bennée wrote:
>> Hi,
>>
>> As we consider the next cycle for Project Stratos I would like to make
>> some more progress on hypervisor agnosticism for our virtio backends.
>> While we have implemented a number of
implementation, a Jailhouse
> implementation, etc. -- work together toward the common goal of a single
> BE source (not binary) supporting multiple different deployment models.
>
>
> [1] https://github.com/OpenAMP/kvmtool
--
Alex Bennée
or would we want to
have at least some of the higher level rust-vmm abstractions for dealing
with navigating the virtqueues and responding and filling in data?
Thoughts?
--
Alex Bennée
s well.
> The notes from the Xen Summit Design Session on VirtIO Cross-Project BoF for
> Xen and Guest OS, which include context about the
> several separate approaches to VirtIO on Xen, have now been posted here:
> https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg00472.html
Thanks for the link - looks like a very detailed summary.
>
> Christopher
>
>
> -Takahiro Akashi
--
Alex Bennée
the bootstrap of the virtio-proxy channel happens and
the second is how many context switches are involved in a transaction.
Of course with all things there is a trade off. Things involving the
very tightest latency would probably opt for a bare metal backend which
I think would imply hypervisor knowledge in the backend binary.
>
> If kvm's ioregionfd can fit into this protocol, virtio-proxy for kvm
> will hopefully be implemented using ioregionfd.
>
> -Takahiro Akashi
>
> [1] https://op-lists.linaro.org/pipermail/stratos-dev/2021-August/000548.html
--
Alex Bennée
true our focus is just VirtIO which does support alternative
transport options however most implementations seem to be targeting
virtio-mmio for it's relative simplicity and understood semantics
(modulo a desire for MSI to reduce round trip latency handling
signalling).
>
> Stefan
>
> [[End of PGP Signed Part]]
--
Alex Bennée
code (as a set of virtio BEs)
> is a requirement here.
When I hear people referring to VirtIO HALs I'm thinking mainly of
VirtIO FE's living in a Linux kernel. There are certainly more devices
that can get added but the commonality on the guest side I think is
pretty much a solved problem (modulo Linux-ism's creeping into the
virtio spec).
--
Alex Bennée
> rom_set_fw(fw_cfg);
Gentle ping. The fix looks perfectly sane to me but I don't have any x86
Xen HW to test this one. Are the x86 maintainers happy to take this on?
FWIW:
Reviewed-by: Alex Bennée
--
Alex Bennée
Julien Grall writes:
> On 28/05/2021 13:49, Alex Bennée wrote:
>> Hi,
>
> Hi Alex,
>
>> I'm currently trying to pull together the threads for booting Xen on
>> Debian. I'm currently doing this within QEMU's TCG emulation and the
>> "virt" machine
reciate that ACPI is the preferred enterprise way of booting but at
the moment I think FDT is probably preferred because:
- lack of real HW with decent ACPI (my MachiatoBin only boots with DT)
- I want to try additional hypervisors who don't have ACPI aware
implementations
That said if I can get an ACPI version of Xen booting via Grub that
would be an improvement.
--
Alex Bennée
These tests make sure we can boot the Xen hypervisor with a Dom0
kernel using the guest-loader. We currently have to use a kernel I
built myself because there are issues using the Debian kernel images.
Signed-off-by: Alex Bennée
Tested-by: Cleber Rosa
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Message-Id: <20201105175153.30489-7-alex.ben...@linaro.org>
Message-Id: <20210211171945.18313-7-alex.ben...@linaro.org>
---
docs/system/guest-loader.rst | 54
docs/system/index.rst
We might as well surface this useful information in the manual so
users can find it easily. It is a fairly simple conversion to rst with
the only textual fixes being QemuOps to QemuOpts.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Message-Id: <20201105175153.30489-6-alex.
A string array in device tree is simply a series of \0 terminated
strings next to each other. As libfdt doesn't support that directly
we need to build it ourselves.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Message-Id: <20201105175153.30489-4-alex.ben...@linaro.org>
Mess
\
-append "dom0_mem=1G,max:1G loglvl=all guest_loglvl=all" \
-device guest-loader,addr=0x4200,kernel=Image,bootargs="root=/dev/sda2
ro console=hvc0 earlyprintk=xen" \
-device guest-loader,addr=0x4700,initrd=rootfs.cpio
Signed-off-by: Alex Bennée
Message-Id: <
The use of FDT's is quite common across our various platforms. To
allow the guest loader to tweak it we need to make it available in
the generic state. This creates the field and migrates the initial
user to use the generic field. Other boards will be updated in later
patches.
Signed-off-by: Alex
from going in. However if you would like to
review it please do ;-)
The only real change is a tweak to the final patch where I've added a
stable archive URL for the Debian Xen packages.
Alex Bennée (7):
hw/board: promote fdt from ARM VirtMachineState to MachineState
hw/riscv: migrate fdt field
This is a mechanical change to make the fdt available through
MachineState.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210211171945.18313-3-alex.ben...@linaro.org>
---
include/hw/riscv/virt.h | 1 -
hw/riscv/virt.c
Alex Bennée writes:
> Hi,
>
> These patches have been sitting around as part of a larger series to
> improve the support of Xen on AArch64. The second part of the work is
> currently awaiting other re-factoring and build work to go in to make
> the building of a pure-Xen c
These tests make sure we can boot the Xen hypervisor with a Dom0
kernel using the guest-loader. We currently have to use a kernel I
built myself because there are issues using the Debian kernel images.
Signed-off-by: Alex Bennée
---
MAINTAINERS | 1 +
tests/acceptance
We might as well surface this useful information in the manual so
users can find it easily. It is a fairly simple conversion to rst with
the only textual fixes being QemuOps to QemuOpts.
Signed-off-by: Alex Bennée
Message-Id: <20201105175153.30489-6-alex.ben...@linaro.org>
---
v2
Signed-off-by: Alex Bennée
Message-Id: <20201105175153.30489-7-alex.ben...@linaro.org>
---
v2
- add docs and MAINTAINERS
---
docs/system/guest-loader.rst | 54
docs/system/index.rst| 1 +
MAINTAINERS | 1 +
3 files chang
A string array in device tree is simply a series of \0 terminated
strings next to each other. As libfdt doesn't support that directly
we need to build it ourselves.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Message-Id: <20201105175153.30489-4-alex.ben...@linaro.org>
This is a mechanical change to make the fdt available through
MachineState.
Signed-off-by: Alex Bennée
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201021170842.25762-3-alex.ben...@linaro.org>
Message-Id: <20201105175153.30489-3-alex.ben...@l
-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-2-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
v2
- rebase
---
include/hw/arm/virt.h | 1 -
include/hw/boards.h | 1 +
hw/arm/virt.c | 356 ++-
n...@linaro.org>
Signed-off-by: Alex Bennée
---
v2
- use PRIx64 format string
- fix long lines to assuage checkpatch
- add MAINTAINERS entry
- use current_machine->ram_size
- checkpatch fixes
---
hw/core/guest-loader.h | 34 ++
1 - 100 of 135 matches
Mail list logo
