From: Peter Maydell <peter.maydell@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: explain device-to-transport mapping in create_virtio_devices()
Date: Tue, 3 Feb 2015 11:51:16 +0000 [thread overview]
Message-ID: <CAFEAcA8f=5wcz_9DXc9JUsULVMTYLdO4Oh3QOEaEOnNaP9PDjA@mail.gmail.com> (raw)
In-Reply-To: <54CB09E2.9040506@redhat.com>
On 30 January 2015 at 04:34, Laszlo Ersek <lersek@redhat.com> wrote:
> Peter,
>
> On 01/30/15 05:31, Laszlo Ersek wrote:
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> hw/arm/virt.c | 32 ++++++++++++++++++++++++++++----
>> 1 file changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 2353440..091e5ee 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -441,10 +441,27 @@ static void create_virtio_devices(const VirtBoardInfo *vbi, qemu_irq *pic)
>> int i;
>> hwaddr size = vbi->memmap[VIRT_MMIO].size;
>>
>> - /* Note that we have to create the transports in forwards order
>> - * so that command line devices are inserted lowest address first,
>> - * and then add dtb nodes in reverse order so that they appear in
>> - * the finished device tree lowest address first.
>> + /* We create the transports in forwards order. Since qbus_realize()
>> + * prepends (not appends) new child buses, the incrementing loop below will
>> + * create a list of virtio-mmio buses with decreasing base addresses.
>> + *
>> + * When a -device option is processed from the command line,
>> + * qbus_find_recursive() picks the next free virtio-mmio bus in forwards
>> + * order. The upshot is that -device options in increasing command line
>> + * order are mapped to virtio-mmio buses with decreasing base addresses.
>> + *
>> + * When this code was originally written, that arrangement ensured that the
>> + * guest Linux kernel would give the lowest "name" (/dev/vda, eth0, etc) to
>> + * the first -device on the command line. (The end-to-end order is a
>> + * function of this loop, qbus_realize(), qbus_find_recursive(), and the
>> + * guest kernel's name-to-address assignment strategy.)
>> + *
>> + * Meanwhile, the kernel's traversal seems to have been reserved; see eg.
>
> can you please s/reserved/reversed/?
>
> Result of over-editing, sorry.
Sure, no problem. I also suggest I add this para:
*
* In any case, the kernel makes no guarantee about the stability of
* enumeration order of virtio devices (as demonstrated by it changing
* between kernel versions). For reliable and stable identification
* of disks users must use UUIDs or similar mechanisms.
-- PMM
next prev parent reply other threads:[~2015-02-03 11:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 4:31 [Qemu-devel] [PATCH] hw/arm/virt: explain device-to-transport mapping in create_virtio_devices() Laszlo Ersek
2015-01-30 4:34 ` Laszlo Ersek
2015-02-03 11:51 ` Peter Maydell [this message]
2015-02-03 12:04 ` Laszlo Ersek
2015-02-03 12:09 ` Peter Maydell
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='CAFEAcA8f=5wcz_9DXc9JUsULVMTYLdO4Oh3QOEaEOnNaP9PDjA@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).