qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] About making QEMU to LIBs!


From: Yang Zhong
Subject: Re: [Qemu-devel] About making QEMU to LIBs!
Date: Tue, 26 Mar 2019 19:38:47 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 26, 2019 at 10:07:35AM +0100, Paolo Bonzini wrote:
> On 26/03/19 08:00, Xiao Guangrong wrote:
> > On 3/26/19 7:18 AM, Paolo Bonzini wrote:
> >> Also, what is the use case?  Is it to reduce the attack surface without
> >> having multiple QEMU binaries?
> > 
> > Security is one story we concern, only the essential and audited
> > modules/libraries can be loaded into memory.
> >
> > Another story is that lightweight virt. becomes more and more important
> > to run VM-based workload in the public Cloud. However, QEMU is too huge
> > and cumbersome to fill our requirements, e.g, QEMU-lites has been being
> > developed for a long time but still lacks a way into mainline or
> > Intel's nEMU more radically.
> 
> What is your definition of lightweight?  To some extent, moving devices
> to separate dynamic libraries _adds_ weight for the mechanisms to load
> those libraries dynamically.
> 
> Would separate QEMU binaries be a solution?  I think I am not as opposed
> to a "q35-lite" machine type these days, I find it preferrable to share
> the northbridge and southbridge with Q35 and just get rid of IDE, VGA,
> IOAPIC, legacy ISA devices etc.  The chipset would stay the same as q35
> so that we keep secure boot, share the code for ACPI stuff (hotplug),
> and if the OS needs it we can also add back the RTC.
> 
  Paolo, i am doing NEMU rebase work and will make up these patches for
  upstream. You do not want to add extra machine type for x86 ? There
  are two type of light weight solutions in our intel
  1) qemu-lite
     PVH has been merged into Qemu 4.0, which seems there is no chance
     for our skip bios solution for upstream?
  2) NEMU
     Our previous plan is to upstream NEMU's virt platform into Qemu.

  Thanks!

  Yang

> Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]