[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