All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: kwolf@redhat.com, peter.maydell@linaro.org,
	qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
	qemu-arm@nongnu.org, lersek@redhat.com
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev
Date: Fri, 12 Apr 2019 14:35:12 +0200	[thread overview]
Message-ID: <87mukvo0zj.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <95f2e6d2-5bd0-a9dc-ab4b-dc172e7f1ad1@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Thu, 11 Apr 2019 16:35:13 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 4/11/19 3:56 PM, Markus Armbruster wrote:
>> The ARM virt machines put firmware in flash memory.  To configure it,
>> you use -drive if=pflash,unit=0,... and optionally -drive
>> if=pflash,unit=1,...
>> 
>> Why two -drive?  This permits setting up one part of the flash memory
>> read-only, and the other part read/write.  It also makes upgrading
>> firmware on the host easier.  Below the hood, we get two separate
>> flash devices, because we were too lazy to improve our flash device
>> models to support sector protection.
>> 
>> The problem at hand is to do the same with -blockdev somehow, as one
>> more step towards deprecating -drive.
>> 
>> We recently solved this problem for x86 PC machines, in commit
>> ebc29e1beab.  See the commit message for design rationale.
>> 
>> This commit solves it for ARM virt basically the same way: new machine
>> properties pflash0, pflash1 forward to the onboard flash devices'
>> properties.  Requires creating the onboard devices in the
>> .instance_init() method virt_instance_init().  The existing code to
>> pick up drives defined with -drive if=pflash is replaced by code to
>> desugar into the machine properties.
>> 
>> There are a few behavioral differences, though:
>> 
>> * The flash devices are always present (x86: only present if
>>   configured)
>> 
>> * Flash base addresses and sizes are fixed (x86: sizes depend on
>>   images, mapped back to back below a fixed address)
>> 
>> * -bios configures contents of first pflash (x86: -bios configures ROM
>>    contents)
>> 
>> * -bios is rejected when first pflash is also configured with -machine
>>    pflash0=... (x86: bios is silently ignored then)
>
> Can we start deprecating the -bios command line option?
>
> Maybe on a per-architecture basis first.

I have no idea.

Perhaps we want to keep it as syntactic sugar for convenience.  Right
now it's something else: an ugly special case.

Of course, the name -bios is a bit PC-centric.  And even there it makes
less sense than it used to.

[...]

WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com,
	peter.maydell@linaro.org, qemu-block@nongnu.org,
	mreitz@redhat.com, qemu-arm@nongnu.org, lersek@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev
Date: Fri, 12 Apr 2019 14:35:12 +0200	[thread overview]
Message-ID: <87mukvo0zj.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <95f2e6d2-5bd0-a9dc-ab4b-dc172e7f1ad1@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Thu, 11 Apr 2019 16:35:13 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 4/11/19 3:56 PM, Markus Armbruster wrote:
>> The ARM virt machines put firmware in flash memory.  To configure it,
>> you use -drive if=pflash,unit=0,... and optionally -drive
>> if=pflash,unit=1,...
>> 
>> Why two -drive?  This permits setting up one part of the flash memory
>> read-only, and the other part read/write.  It also makes upgrading
>> firmware on the host easier.  Below the hood, we get two separate
>> flash devices, because we were too lazy to improve our flash device
>> models to support sector protection.
>> 
>> The problem at hand is to do the same with -blockdev somehow, as one
>> more step towards deprecating -drive.
>> 
>> We recently solved this problem for x86 PC machines, in commit
>> ebc29e1beab.  See the commit message for design rationale.
>> 
>> This commit solves it for ARM virt basically the same way: new machine
>> properties pflash0, pflash1 forward to the onboard flash devices'
>> properties.  Requires creating the onboard devices in the
>> .instance_init() method virt_instance_init().  The existing code to
>> pick up drives defined with -drive if=pflash is replaced by code to
>> desugar into the machine properties.
>> 
>> There are a few behavioral differences, though:
>> 
>> * The flash devices are always present (x86: only present if
>>   configured)
>> 
>> * Flash base addresses and sizes are fixed (x86: sizes depend on
>>   images, mapped back to back below a fixed address)
>> 
>> * -bios configures contents of first pflash (x86: -bios configures ROM
>>    contents)
>> 
>> * -bios is rejected when first pflash is also configured with -machine
>>    pflash0=... (x86: bios is silently ignored then)
>
> Can we start deprecating the -bios command line option?
>
> Maybe on a per-architecture basis first.

I have no idea.

Perhaps we want to keep it as syntactic sugar for convenience.  Right
now it's something else: an ugly special case.

Of course, the name -bios is a bit PC-centric.  And even there it makes
less sense than it used to.

[...]

WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: kwolf@redhat.com, peter.maydell@linaro.org,
	qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
	qemu-arm@nongnu.org, lersek@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev
Date: Fri, 12 Apr 2019 14:35:12 +0200	[thread overview]
Message-ID: <87mukvo0zj.fsf@dusky.pond.sub.org> (raw)
Message-ID: <20190412123512.SOrQB23alk3Ng66koxoteR9Do_O90uH1GFHRJ5OZaZ4@z> (raw)
In-Reply-To: <95f2e6d2-5bd0-a9dc-ab4b-dc172e7f1ad1@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Thu, 11 Apr 2019 16:35:13 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 4/11/19 3:56 PM, Markus Armbruster wrote:
>> The ARM virt machines put firmware in flash memory.  To configure it,
>> you use -drive if=pflash,unit=0,... and optionally -drive
>> if=pflash,unit=1,...
>> 
>> Why two -drive?  This permits setting up one part of the flash memory
>> read-only, and the other part read/write.  It also makes upgrading
>> firmware on the host easier.  Below the hood, we get two separate
>> flash devices, because we were too lazy to improve our flash device
>> models to support sector protection.
>> 
>> The problem at hand is to do the same with -blockdev somehow, as one
>> more step towards deprecating -drive.
>> 
>> We recently solved this problem for x86 PC machines, in commit
>> ebc29e1beab.  See the commit message for design rationale.
>> 
>> This commit solves it for ARM virt basically the same way: new machine
>> properties pflash0, pflash1 forward to the onboard flash devices'
>> properties.  Requires creating the onboard devices in the
>> .instance_init() method virt_instance_init().  The existing code to
>> pick up drives defined with -drive if=pflash is replaced by code to
>> desugar into the machine properties.
>> 
>> There are a few behavioral differences, though:
>> 
>> * The flash devices are always present (x86: only present if
>>   configured)
>> 
>> * Flash base addresses and sizes are fixed (x86: sizes depend on
>>   images, mapped back to back below a fixed address)
>> 
>> * -bios configures contents of first pflash (x86: -bios configures ROM
>>    contents)
>> 
>> * -bios is rejected when first pflash is also configured with -machine
>>    pflash0=... (x86: bios is silently ignored then)
>
> Can we start deprecating the -bios command line option?
>
> Maybe on a per-architecture basis first.

I have no idea.

Perhaps we want to keep it as syntactic sugar for convenience.  Right
now it's something else: an ugly special case.

Of course, the name -bios is a bit PC-centric.  And even there it makes
less sense than it used to.

[...]


  reply	other threads:[~2019-04-12 12:50 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 13:56 [Qemu-arm] [PATCH 0/2] hw/arm/virt: Support firmware configuration with -blockdev Markus Armbruster
2019-04-11 13:56 ` [Qemu-devel] " Markus Armbruster
2019-04-11 13:56 ` Markus Armbruster
2019-04-11 13:56 ` [Qemu-arm] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive() Markus Armbruster
2019-04-11 13:56   ` [Qemu-devel] " Markus Armbruster
2019-04-11 13:56   ` Markus Armbruster
2019-04-11 19:35   ` [Qemu-arm] " Laszlo Ersek
2019-04-11 19:35     ` Laszlo Ersek
2019-04-11 19:35     ` Laszlo Ersek
2019-04-11 19:50     ` [Qemu-arm] " Laszlo Ersek
2019-04-11 19:50       ` Laszlo Ersek
2019-04-11 19:50       ` Laszlo Ersek
2019-04-11 20:04       ` Laszlo Ersek
2019-04-11 20:04         ` Laszlo Ersek
2019-04-12  7:52         ` [Qemu-arm] " Markus Armbruster
2019-04-12  7:52           ` Markus Armbruster
2019-04-12  7:52           ` Markus Armbruster
2019-04-12 11:18           ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-04-12 11:18             ` Philippe Mathieu-Daudé
2019-04-12 12:26           ` [Qemu-arm] " Markus Armbruster
2019-04-12 12:26             ` Markus Armbruster
2019-04-12 12:26             ` Markus Armbruster
2019-04-12 12:32           ` [Qemu-arm] " Laszlo Ersek
2019-04-12 12:32             ` Laszlo Ersek
2019-04-12 12:32             ` Laszlo Ersek
2019-04-11 13:56 ` [Qemu-arm] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev Markus Armbruster
2019-04-11 13:56   ` [Qemu-devel] " Markus Armbruster
2019-04-11 13:56   ` Markus Armbruster
2019-04-11 14:35   ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-04-11 14:35     ` Philippe Mathieu-Daudé
2019-04-12 12:35     ` Markus Armbruster [this message]
2019-04-12 12:35       ` Markus Armbruster
2019-04-12 12:35       ` Markus Armbruster
2019-04-12 11:00   ` [Qemu-arm] " Laszlo Ersek
2019-04-12 11:00     ` Laszlo Ersek
2019-04-12 11:00     ` Laszlo Ersek
2019-04-12 17:49     ` [Qemu-arm] " Markus Armbruster
2019-04-12 17:49       ` Markus Armbruster
2019-04-12 17:49       ` Markus Armbruster
2019-04-12 21:33       ` [Qemu-arm] " Laszlo Ersek
2019-04-12 21:33         ` Laszlo Ersek
2019-04-12 21:33         ` Laszlo Ersek
2019-04-13  5:40         ` [Qemu-arm] " Markus Armbruster
2019-04-13  5:40           ` Markus Armbruster
2019-04-13  5:40           ` Markus Armbruster

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=87mukvo0zj.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.