[Rust-VMM] [Rust-vmm] Goals for this list

[Jiang Liu]

> On Dec 20, 2018, at 7:17 AM, Boeuf, Sebastien <sebastien.boeuf at intel.com> wrote:
> 
> On Wed, 2018-12-19 at 15:02 -0800, Dylan Reid wrote:
>> On Wed, Dec 19, 2018 at 2:59 PM Steve Rutherford <srutherford at google.
>> com> wrote:
>>> 
>>> 
>>> Hint received :)
>>> Getting userspace instruction emulation to work with nested has
>>> been a
>>> bit of a fight, and we've been waiting to push stuff upstream until
>>> we
>>> have it everywhere.
>> The crosvm team is currently investigating moving the PIT and APIC
>> emulation to user space. If that works, instruction emulation will be
>> next on the list, including helping to get the kernel side landed
>> upstream.
>> 
> 
> That's nice! Quick question, why do you want to emulate the PIT? If you
> emulate APIC feature X86_FEATURE_TSC_DEADLINE_TIMER, the legacy timer
> emulation should not be required, right?
> Oh I guess that's because some other architectures might need the PIT.
> 
> Are you planning to make this modular so that we could choose to pick
> only the APIC emulation?
> 
Yeah, APIC deadline timer could be used here so we could remove PIT, even
PIC and Local APIC. We have done a quick PoC by using NetBSD and uKVM.
I think it should work with Linux too. 


>>> 
>>> 
>>> On Wed, Dec 19, 2018 at 1:13 PM Paolo Bonzini <pbonzini at redhat.com>
>>> wrote:
>>>> 
>>>> 
>>>> On 18/12/18 00:30, Liguori, Anthony wrote:
>>>>> 
>>>>> As a side note, I think having OS X hypervisor framework
>>>>> bindings
>>>>> and whatever the new Windows thing is would be pretty cool.
>>>> Yes, indeed.  Hypervisor.framework however is much more complex
>>>> than KVM
>>>> or WHP because you deal manually with VMCSes and have to do
>>>> instruction
>>>> emulation in userspace.  QEMU takes a stab at it, but it's not as
>>>> stable
>>>> as KVM.
>>>> 
>>>> *However* Google does have patches for KVM to do instruction
>>>> emulation
>>>> in userspace, and I'd like to apply them upstream too now that
>>>> KVM has
>>>> an API test framework (and thus we can know they won't bitrot).
>>>> (Steve, you are in Cc because hint, hint :)).  Once that is in
>>>> place, I
>>>> guess a minimal x86 emulator written in Rust, porting the
>>>> emulator code
>>>> that QEMU has for Hypervisor.framework, would be a fun GSoC
>>>> project for
>>>> a very good student.
>>>> 
>>>>> 
>>>>> 2) The crosvm data_model crate.  This one is super critical but
>>>>> easy to
>>>>> misunderstand as it allows for safe access to volatile
>>>>> memory.  Somewhat
>>>>> related is the mmap() bits from sys_util.  Not sure how the
>>>>> crosvm folks
>>>>> feel but I think there is some refactoring here that could be
>>>>> useful to
>>>>> build a memory crate.
>>>>> 
>>>>> 3) Some traits for device model implementations.  It's easy to
>>>>> really
>>>>> bike shed here so I reckon it's best to start with a concrete
>>>>> device
>>>>> model like a UART, work through what is required for
>>>>> interfaces, and
>>>>> then iterate from there.
>>>>> 
>>>>> 4) Common device models with only a single implementation (i.e.
>>>>> 16650A).  Not sure about virtio, maybe.
>>>> virtio would be interesting.  One initial target could be a demo
>>>> vhost-user client, it has to set up a memory map, parse vrings,
>>>> handle
>>>> endianness, etc.  It would be an interesting benchmark for a DMA
>>>> API.
>>>> 
>>>> The control plane (your item 3) by comparison is a bit less
>>>> interesting.
>>>> 
>>>> Paolo
>>> _______________________________________________
>>> Rust-vmm mailing list
>>> Rust-vmm at lists.opendev.org
>>> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
>> _______________________________________________
>> Rust-vmm mailing list
>> Rust-vmm at lists.opendev.org
>> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org <mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm <http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20181220/a501b5d5/attachment-0001.html>