Paolo Bonzini writes:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and the
>> one we don't want to affect happens to ignore the property value.
>
> Is this true?
The other day, I described how my attempt to implement Paolo's
suggestion to add block properties to the machine ran into difficulties.
To recap briefly, creating devices within a machine's .instance_init()
crashes. Turns out device_post_init() calls qdev_get_machine(), which
calls
Laszlo Ersek writes:
> Hi Markus,
>
> On 02/07/19 10:30, Markus Armbruster wrote:
>> The thread got long, let me try to summarize, and elaborate a few
>> points.
>>
>> * The problem at hand is configuring firmware residing in flash memory
>> (OVMF requires this) without legacy -drive.
>>
>>
On 01/02/19 03:49, Ning, Yu wrote:
> Thank you both for outlining the changes we have to make in order to
> support ROMD memory regions! The only question is whether we should
> pass a new flag to HAX_VM_IOCTL_SET_RAM2 for ROMD, so the hypervisor
> could respond differently to writes to ROM and
>> This is all greek to me. I take it there's something wrong with these
>> accelerators that makes (read-only?) flash memory not work, even
>> though the read-only mapping we now create for traditional BIOS works.
>> Weird, but I'm of course willing to take your word for it.
> Yes, as I
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, February 1, 2019 7:55
> To: Alexandro Sanchez Bach ; 'Markus Armbruster'
>
> Cc: 'Peter Maydell' ; 'Peter Krempa'
> ; 'Qemu-block' ; 'Libvirt'
> ; 'QEMU Developers' ;
> 'László Érsek' ; 'Justin Terry
Paolo Bonzini writes:
> On 31/01/19 13:12, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 31/01/19 10:41, Markus Armbruster wrote:
Paolo Bonzini writes:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the
On 01/02/19 00:28, Alexandro Sanchez Bach wrote:
> (CC'd Yu Ning @ Intel's HAXM team)
>
> Not sure, if I'm understanding the issue correctly, but isn't
> `HAX_VM_IOCTL_SET_RAM2` with the `HAX_RAM_INFO_ROM` flag precisely
> what you are looking for?
>
> More precisely, HAX_VM_IOCTL_SET_RAM2 maps
On 31/01/19 13:12, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 10:41, Markus Armbruster wrote:
>>> Paolo Bonzini writes:
>>>
On 31/01/19 09:40, Markus Armbruster wrote:
>> Maybe we should just add pflash block properties to the machine? And
>> then it can
Paolo Bonzini writes:
> On 31/01/19 10:37, Markus Armbruster wrote:
>>>
Hmm, why is it okay to treat all pfl->cmd values the same when
secure=on?
>>> But doesn't matter. You just don't want MMIO mode to be active outside
>>> SMM: all that non-SMM code want to do with the flash is read
Paolo Bonzini writes:
> On 31/01/19 10:41, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 31/01/19 09:40, Markus Armbruster wrote:
> Maybe we should just add pflash block properties to the machine? And
> then it can create the devices if the properties are set to a
On 31/01/19 10:37, Markus Armbruster wrote:
>>
>>> Hmm, why is it okay to treat all pfl->cmd values the same when
>>> secure=on?
>> But doesn't matter. You just don't want MMIO mode to be active outside
>> SMM: all that non-SMM code want to do with the flash is read and execute
>> it, as far as
Peter Maydell writes:
> On Thu, 31 Jan 2019 at 10:24, Markus Armbruster wrote:
>> 1. Make the device model default to some "correct" configuration, even
>> if that setting is kind of arbitrary. That way, any code using new
>> style gets an "incorrect" configuration only if it actively selects
On 01/31/19 10:37, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 09:33, Markus Armbruster wrote:
>>> I thought secure=on affected only writes (and so wouldn't matter with
>>> readonly=on), but I was wrong:
>>>
>>> static MemTxResult pflash_mem_read_with_attrs(void
On 01/31/19 10:19, Paolo Bonzini wrote:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the machine? And
>>> then it can create the devices if the properties are set to a non-empty
>>> value.
>> What exactly do you have in mind? Something
On Thu, 31 Jan 2019 at 10:24, Markus Armbruster wrote:
> 1. Make the device model default to some "correct" configuration, even
> if that setting is kind of arbitrary. That way, any code using new
> style gets an "incorrect" configuration only if it actively selects one.
I don't think that's
Peter Maydell writes:
> On Thu, 31 Jan 2019 at 08:52, Markus Armbruster wrote:
>> Lesson for the future: when we correct something, but don't dare to
>> touch (some) existing uses (being not "reasonably sure it doesn't
>> actually break guests that used to work"), we should at least have
>>
On 31/01/19 10:41, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 09:40, Markus Armbruster wrote:
Maybe we should just add pflash block properties to the machine? And
then it can create the devices if the properties are set to a non-empty
value.
>>> What
On Thu, 31 Jan 2019 at 08:52, Markus Armbruster wrote:
> Lesson for the future: when we correct something, but don't dare to
> touch (some) existing uses (being not "reasonably sure it doesn't
> actually break guests that used to work"), we should at least have
> enough sense to make "incorrect"
Paolo Bonzini writes:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the machine? And
>>> then it can create the devices if the properties are set to a non-empty
>>> value.
>> What exactly do you have in mind? Something like
>>
>>
Paolo Bonzini writes:
> On 31/01/19 09:33, Markus Armbruster wrote:
>> I thought secure=on affected only writes (and so wouldn't matter with
>> readonly=on), but I was wrong:
>>
>> static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr,
>> uint64_t *value,
>>
On 31/01/19 09:40, Markus Armbruster wrote:
>> Maybe we should just add pflash block properties to the machine? And
>> then it can create the devices if the properties are set to a non-empty
>> value.
> What exactly do you have in mind? Something like
>
> -machine
On 31/01/19 09:33, Markus Armbruster wrote:
> I thought secure=on affected only writes (and so wouldn't matter with
> readonly=on), but I was wrong:
>
> static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr,
> uint64_t *value,
>
Peter Maydell writes:
> On Wed, 30 Jan 2019 at 16:44, Laszlo Ersek wrote:
>>
>> On 01/30/19 16:24, Peter Maydell wrote:
>>
>> > Well, nobody who does anything with x86 has cared enough to
>> > make the pflash implementation actually correct.
>>
>> I feel sort of included under this umbrella,
Paolo Bonzini writes:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and the
>> one we don't want to affect happens to ignore the property value.
>
> Is this true?
Laszlo Ersek writes:
> On 01/30/19 15:33, Paolo Bonzini wrote:
>> On 30/01/19 15:13, Markus Armbruster wrote:
>>> -global driver=cfi.pflash01,property=secure,value=on
>>>
>>> Affects *all* such devices, but fortunately we have at most two, and
>>> the one we don't want to affect happens to
On Wed, 30 Jan 2019 at 16:44, Laszlo Ersek wrote:
>
> On 01/30/19 16:24, Peter Maydell wrote:
>
> > Well, nobody who does anything with x86 has cared enough to
> > make the pflash implementation actually correct.
>
> I feel sort of included under this umbrella, so:
>
> I haven't been aware of any
On 01/30/19 16:24, Peter Maydell wrote:
> Well, nobody who does anything with x86 has cared enough to
> make the pflash implementation actually correct.
I feel sort of included under this umbrella, so:
I haven't been aware of any particular pflash implementation errors. I
"didn't care" because
On 01/30/19 15:33, Paolo Bonzini wrote:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and
>> the one we don't want to affect happens to ignore the property value.
>
>
On Wed, 30 Jan 2019 at 07:24, Markus Armbruster wrote:
>
> Let me reply to the "why is the cfi.pflash01 device so weird" part
> first, because that's relatively quick, and because it could easily
> distract us from the more important "how do we want to configure OVMF"
> part. I'll reply to that
On 30/01/19 15:13, Markus Armbruster wrote:
> -global driver=cfi.pflash01,property=secure,value=on
>
> Affects *all* such devices, but fortunately we have at most two, and the
> one we don't want to affect happens to ignore the property value.
Is this true? I think both need secure=on, at
Cc: Paolo for additonal device infrastructure expertise.
Peter Maydell writes:
> On Fri, 25 Jan 2019 at 15:11, Markus Armbruster wrote:
>> (1) cfi.pflash01 isn't available with -device.
>>
>> (2) "Magic board code picks up the backend [created for -drive
>> if=pflash], creates a frontend
Hi,
> > (Migration compat is left as an exercise for the reader :-))
>
> It's not just migration compatibility, it's also guest ABI: "the guest
> can tell the difference".
Is that actually the case on x86? I don't think so.
Note: arm is different, because the flash is listed in the device
Peter Maydell writes:
> On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann wrote:
>> The tricky part is the access control here. On physical hardware you
>> typically have one flash rom, say 16M below 4G (on x86).
>>
>> Our pflash device doesn't allow to define multiple regions, so we use
>> multiple
Let me reply to the "why is the cfi.pflash01 device so weird" part
first, because that's relatively quick, and because it could easily
distract us from the more important "how do we want to configure OVMF"
part. I'll reply to that part later.
Peter Maydell writes:
> On Fri, 25 Jan 2019 at
On 01/28/19 15:58, Peter Maydell wrote:
> On Mon, 28 Jan 2019 at 14:56, Laszlo Ersek wrote:
>> Regarding OVMF, I kept the flash driver intentionally in the dark about
>> split vs. unified pflash, so OVMF will not care, as long as the same
>> GPAs behave the same as before.
>>
>> Regarding
On Mon, 28 Jan 2019 at 14:56, Laszlo Ersek wrote:
> Regarding OVMF, I kept the flash driver intentionally in the dark about
> split vs. unified pflash, so OVMF will not care, as long as the same
> GPAs behave the same as before.
>
> Regarding ArmVirtQemu, I'm not so sure. It think it already
On 01/28/19 14:06, Peter Maydell wrote:
> On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann wrote:
>> The tricky part is the access control here. On physical hardware you
>> typically have one flash rom, say 16M below 4G (on x86).
>>
>> Our pflash device doesn't allow to define multiple regions, so we
On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann wrote:
> The tricky part is the access control here. On physical hardware you
> typically have one flash rom, say 16M below 4G (on x86).
>
> Our pflash device doesn't allow to define multiple regions, so we use
> multiple pflash devices instead, each
Hi,
> > Issue (1) isn't too hard: we add the device to the dynamic sysbus device
> > white-list, move a sysbus_mmio_map() from pflash_cfi01_realize() into
> > pflash_cfi01_realize(). The latter requires a new device property to
> > configure the base address. I got a working prototype. Since
On Fri, 25 Jan 2019 at 15:11, Markus Armbruster wrote:
> (1) cfi.pflash01 isn't available with -device.
>
> (2) "Magic board code picks up the backend [created for -drive
> if=pflash], creates a frontend (a cfi.pflash01 device), and maps it
> into the guest's address space." When we
41 matches
Mail list logo
