> On 20 Oct 2018, at 4:01 am, Sergio Lopez <[email protected]> wrote:
>
> On Wed, Oct 17, 2018 at 02:04:46PM -0700, Mike Larkin wrote:
>> On Fri, Oct 05, 2018 at 01:50:10PM +0200, Sergio Lopez wrote:
>>> Right now, vmd already features an excellent privsep model to ensure
>>> the process servicing the VM requests to the outside world is running
>>> with the lowest possible privileges.
>>>
>>> I was wondering if we could take a step further, servicing each virtio
>>> device from a different process. This design would simplify the
>>> implementation and maintenance of those devices, improve the privsep
>>> model and increase the resilience of VMs (the crash of a process
>>> servicing a device won't bring down the whole VM, and a mechanism to
>>> recover from this scenario could be explored).
>>
>> Our model is generally to not try to recover from crashes like that. Indeed,
>> you *want* to crash so the underlying bug can be found and fixed.
>
> With separate processes you'll still have a crash with core dump from
> the process servicing the device, with the additional advantage of being
> able to, optionally, try to recover device or debug it independently.
>
>>> - An in-kernel IRQ chip. This one is the most controversial, as it
>>> means emulating a device from a privileged domain, but I'm pretty sure
>>> a lapic implementation with enough functionality to serve *BSD/Linux
>>> Guests can be small and simple enough to be easily auditable.
>>
>> This needs to be done, for a number of reasons (device emulation being just
>> one). pd@ and I are working on how to implement this using features in
>> recent CPUs, since much of the LAPIC emulation can now be handled by the
>> CPU itself. We're thinking skylake and later will be the line in the sand
>> for this. Otherwise the software emulation is more complex and more prone
>> to bugs. I've resisted the urge to put this stuff in the kernel for exactly
>> that reason, but with later model CPUs we may be in better shape. We may
>> also decide to focus solely on x2APIC. If you're interested in helping in
>> this area, I'll keep you in the loop.
>
> Sure, I'd like to help. I'm quite familiar with KVM's in-kernel irqchip
> implementation.
>
>>> Do you think it's worth exploring this model? What are feelings
>>> regarding the in-kernel IRQ chip?
>>>
>>> Sergio (slp).
>>>
>>
>> All things considered, I'm less sold on the idea of splitting out devices
>> into their own processes. I don't see any compelling reason. But we do
>> need an IOAPIC and LAPIC implementation at some point, as you point out.
>
> Well, vmd is still small enough (thankfully) to be able debug it easily.
> But, eventually, it'll grow in both size and complexity (specially with
> SMP support, I/O optimizations, additional storage backends...) and
> having a high degree of modularity really helps here.
>
> In fact, the QEMU/KVM community is starting to consider going this route
> (but QEMU is *huge*). [1]
>
> Anyways, this is not a "now-or-never" thing. As you suggest, we can work
> now on kickfd and IOAPIC/LAPIC, which are useful by themselves. And when
> those are in place, I'll be able to write a PoC so we can evaluate its
> benefits and drawbacks.
Would sending and receiving a VM still work if I/O is run in different
processes?
dlg
