From: Peter Maydell <peter.maydell@linaro.org>
To: Xu Yandong <xuyandong2@huawei.com>
Cc: wu.wubin@huawei.com, qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Sergio Lopez <slp@redhat.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>
Subject: Re: [PATCH RFC 00/16] Implement Microvm for aarch64 architecture
Date: Mon, 17 Feb 2020 09:56:48 +0000 [thread overview]
Message-ID: <CAFEAcA9ioqVhsBjZZXJDSnSRi-rbz80DZvSv1DsOfN0+NTGA6g@mail.gmail.com> (raw)
In-Reply-To: <1581925888-103620-1-git-send-email-xuyandong2@huawei.com>
On Mon, 17 Feb 2020 at 07:42, Xu Yandong <xuyandong2@huawei.com> wrote:
>
> Implement Microvm for aarch64 architecture
>
> This series attempts to implement microvm for aarch64
> architecture.
>
> Just like how Sergio Lopez does for implementing microvm
> for x86 architecture. We remove parts of emulate devices which
> are not needed in microvm, compared with normal VM,
> We only keep PL011 (UART), PL031 (RTC) and virtio-mmio
> devices for microvm of aarch64.
For x86, 'microvm' makes sense, because the standard
PC models are models of real hardware with a lot of
legacy baggage. The situation is different for aarch64.
The 'virt' board is already intended as a "minimal
machine for booting a VM that knows it's a VM".
Why do we need another model that's intended for the
same purpose?
It would be more interesting to look at whether there
are reasonable places where we could allow command
line options to have the 'virt' board not provide
some devices where that makes a significant speed
improvement. Analysis of where the extra time is
actually going would also be helpful.
NB: I'm pretty firmly against dropping PCI. This is
a pluggable discoverable bus, and it's a much better
way to provide virtio than virtio-mmio.
thanks
-- PMM
prev parent reply other threads:[~2020-02-17 9:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 7:51 [PATCH RFC 00/16] Implement Microvm for aarch64 architecture Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 01/16] hw/arm/arm: Introduce ArmMachineState and ArmMachineClass Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 02/16] hw/arm: move shared fdt member to ArmMachine Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 03/16] hw/arm: move shared memmap " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 04/16] hw/arm: move shared irqmap " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 05/16] hw/arm: move shared smp_cpus " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 06/16] hw/arm/virt: split MSI related codes from create_gic Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 07/16] hw/arm/virt: split virt extension " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 08/16] hw/arm/virt: split secure " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 09/16] hw/arm: move shared gic member to ArmMachine Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 10/16] hw/arm: split create_gic function Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 11/16] hw/arm: move shared psci_enable and claim_edge_triggered_timers member to ArmMachine Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 12/16] hw/arm: move shared devices related functions to arm.c and export them Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 13/16] hw/arm: move shared fdt " Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 14/16] hw/arm: move shared bootinfo member to ArmMachine Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 15/16] hw/arm: move shared cpu related functions to arm.c and export them Xu Yandong
2020-02-17 7:51 ` [PATCH RFC 16/16] hw/arm: Introduce the microvm machine type Xu Yandong
2020-02-17 8:19 ` [PATCH RFC 00/16] Implement Microvm for aarch64 architecture no-reply
2020-02-17 9:56 ` Peter Maydell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA9ioqVhsBjZZXJDSnSRi-rbz80DZvSv1DsOfN0+NTGA6g@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=wu.wubin@huawei.com \
--cc=xuyandong2@huawei.com \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).