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

Jiang Liu liuj97 at gmail.com
Thu Dec 20 01:55:04 UTC 2018



> On Dec 20, 2018, at 9:40 AM, Jiang Liu <liuj97 at gmail.com> wrote:
> 
> 
> 
>> On Dec 20, 2018, at 7:17 AM, Boeuf, Sebastien <sebastien.boeuf at intel.com <mailto: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. 
Sorry, “local APIC” should be “IO APIC”, we still use the in-kernel Local APIC
for MSI and IPI.

> 
> 
>>>> 
>>>> 
>>>> On Wed, Dec 19, 2018 at 1:13 PM Paolo Bonzini <pbonzini at redhat.com <mailto: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 <mailto: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
>> _______________________________________________
>> 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/e4c081ad/attachment.html>


More information about the Rust-vmm mailing list