Il mer 21 mag 2025, 10:37 Paolo Bonzini ha scritto:
> > So... not sure what to do there. It seems like vm-memory is very close
> to
>
>> > being usable by QEMU, but maybe not completely. :(
>>
>> Is it possible or necessary for vm-memory to support overlap? Because I
>> feel that if it is possib
Il mer 21 mag 2025, 11:35 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
> vm-memory is a very rigid API unfortunately. It's excellent for
> rust-vmm purposes. I presume it's possible to figure out a clever
> solution to satisfy both rust-vmm and QEMU use needs but I'm not sure
On Wed, May 21, 2025 at 11:36 AM Paolo Bonzini wrote:
>
>
>
> Il mer 21 mag 2025, 10:21 Zhao Liu ha scritto:
>>
>> I also realize that once FlatRange/FlatView is associated with
>> GuestMemoryRegion/
>> GuestMemory, it changes the usual practice in QEMU, where most memory
>> operations
>> are b
Il mer 21 mag 2025, 10:21 Zhao Liu ha scritto:
> I also realize that once FlatRange/FlatView is associated with
> GuestMemoryRegion/
> GuestMemory, it changes the usual practice in QEMU, where most memory
> operations
> are built around MemoryRegion/AddressSpace.
>
That shouldn't be a problem. I
On Tue, May 20, 2025 at 07:48:11PM +0200, Paolo Bonzini wrote:
> Date: Tue, 20 May 2025 19:48:11 +0200
> From: Paolo Bonzini
> Subject: Re: Rust in QEMU update, April 2025
>
> On 5/20/25 18:23, Zhao Liu wrote:
> > > HPET does some very simple memory accesses; a good safe
On 5/20/25 18:23, Zhao Liu wrote:
HPET does some very simple memory accesses; a good safe solution
for this may be the ``vm-memory`` crate. While I have not looked into
using it, ``vm-memory`` and ``vm-virtio`` were written with QEMU's
use cases in mind.
I'm working on this and trying to wrap s
(Resend as the previous email may have failed.)
> Remaining unsafe code
> '
>
> qdev bindings cover basic classes and interfaces, including
> GPIO pins, timers, clocks and MemoryRegionOps. VMState
> still needs unsafe callbacks for pre_save/post_load, with
> the final version
Il mar 6 mag 2025, 04:41 Manos Pitsidianakis
ha scritto:
> > It's not about hot paths, it's more that 1) you cannot use From/Into in
> > a "static"'s initializer 2) bilge relies a lot on non-const methods in
> > its internal implementation, which makes it quite messy to use it in
> > some places.
On Mon, May 5, 2025 at 4:45 PM Paolo Bonzini wrote:
>
> On 5/5/25 14:26, Manos Pitsidianakis wrote:
> >> Something I do notice is that there's some inconsistency in
> >> how we've structured things between the two devices, e.g.:
> >>
> >> * the pl011 main source file is device.rs, but
On Mon, 5 May 2025 at 14:45, Paolo Bonzini wrote:
>
> On 5/5/25 14:26, Manos Pitsidianakis wrote:
> >> Something I do notice is that there's some inconsistency in
> >> how we've structured things between the two devices, e.g.:
> >>
> >> * the pl011 main source file is device.rs, but th
On 5/5/25 14:26, Manos Pitsidianakis wrote:
Something I do notice is that there's some inconsistency in
how we've structured things between the two devices, e.g.:
* the pl011 main source file is device.rs, but the hpet one
is hpet.rs
* some places we use the actual names o
On Fri, May 2, 2025 at 3:13 PM Paolo Bonzini wrote:
>
> It's been roughly three months since my previous update on the Rust in
> QEMU project. Support for Rust remains experimental, with most of the
> past three months spent cleaning up the bindings and making more
> functionality available from
It's been roughly three months since my previous update on the Rust in
QEMU project. Support for Rust remains experimental, with most of the
past three months spent cleaning up the bindings and making more
functionality available from safe Rust.
As before, this mostly covers what I have looked a
13 matches
Mail list logo
