You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In light of the work we already accomplished with #165, I would like to open this design issue to provide some ideas about refactoring the read_physical API, and implementation.
read_physical_padded
It would be convient to have a read_physical_padded() API,directly available in the Introspectable trait, instead of implementing in the Python layer, at PaddedPhysicalMemoryIO.
It would be more efficient, and available to the C and Rust programs.
moving read algorithms from driver to Introspectable trait
If we take a look at the current implementation for Xen and KVM
Both of them will split the read by 4K chunks, the size of a page.
the proposal would be to move a maximum of this common read algorithm into the Introspectable trait
Proposal
use std::io::Read;traitIntrospectable{fnread_physical(paddr:u64,buf:&mut[u8],bytes_read:&mutu64) -> Result<(),Box<dynError>>{// implementation provided in the traitfor(i, chunk)in buf.chunks_mut(PAGE_SIZE).enumerate(){let new_gfn = xxxx;let page = self.get_physical_page(gfn)?;
page.read(PAGE_SIZE, chunk)?;}}fnread_physical_padded(paddr:u64,buf:&mut[u8],bytes_read:&mutu64) -> Result<(),Box<dynError>>{// same as above, but doesn't stop when a page is missing, fill with zeroes instead}// Return a Readable object that represents a physical page (or frame)fnget_physical_page(gfn:u64) -> Result<Box<dynRead>,Box<dynError>>;}
With this solution we factorise read operation code in the trait, and we can handle the Xen situation where a page has to be mapped / unmapped by returning a Boxed object, that can implement a Drop trait and handle unmapping on deallocation.
The text was updated successfully, but these errors were encountered:
I'm also wondering how we could push the Read trait further into the user API ?
Afterall, we should reuse a maximum of rust traits, and avoiding inventing unecessary APIs.
Also, read_physical() can stay for convenience, but it's implementation could rely on the Read + Seek traits underneath.
Ideas ?
letmut drv = microvmi::init(domain_name,None, init_option).unwrap();// Introspectable trait also implements Read trait
drv.read()// or// return a 'memory' object, which implements the read traitlet memory = drv.memory()
memory.read()// and we can return a second memory object, which implements a padded read
let padded_mem = drv.padded_memory()
padded_mem.read()
In light of the work we already accomplished with #165, I would like to open this design issue to provide some ideas about refactoring the
read_physical
API, and implementation.read_physical_padded
It would be convient to have a
read_physical_padded()
API,directly available in theIntrospectable
trait, instead of implementing in the Python layer, atPaddedPhysicalMemoryIO
.It would be more efficient, and available to the C and Rust programs.
moving read algorithms from driver to Introspectable trait
If we take a look at the current implementation for Xen and KVM
xen read_physical
kvm read_physical
Both of them will split the read by 4K chunks, the size of a page.
the proposal would be to move a maximum of this common read algorithm into the
Introspectable trait
Proposal
With this solution we factorise read operation code in the trait, and we can handle the Xen situation where a page has to be mapped / unmapped by returning a Boxed object, that can implement a
Drop
trait and handle unmapping on deallocation.The text was updated successfully, but these errors were encountered: