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 container_get()
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? I
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.
>>
>> *
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.
>
> * The wider problem is configuring o
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.
* The wider problem is configuring onboard devices. Our general device
configuration interface doesn't
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 RO
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 mach
;Libvirt'
> ; 'QEMU Developers' ;
> 'László Érsek' ; 'Justin Terry (VM)'
> ; Ning, Yu
> Subject: Re: [Qemu-devel] Configuring pflash devices for OVMF firmware
>
> On 01/02/19 00:28, Alexandro Sanchez Bach wrote:
> > (CC'd Yu Ni
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 a
>> 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 wrot
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 crea
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 non-emp
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 th
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 o
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 *opaque,
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 like
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 muc
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
>> enou
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 exactly
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" o
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
>>
>> -mac
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 q35,ovmf-code=OVMF-CODE-NOD
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, so:
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? I
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 ig
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 i
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.
>
> I
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 p
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 le
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 (a
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 15:11
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 repla
(+Peter, keeping the context)
On 01/25/19 16:03, Markus Armbruster wrote:
> We configure OVMF firmware for PC machine types with -drive if=pflash.
> This is pretty much the last remaining use of -drive in libvirt we can't
> yet replace by -blockdev. Such a replacement is desirable, because
> -blo
We configure OVMF firmware for PC machine types with -drive if=pflash.
This is pretty much the last remaining use of -drive in libvirt we can't
yet replace by -blockdev. Such a replacement is desirable, because
-blockdev + -device is more flexible than -drive if=pflash. Also, once
we don't need -
38 matches
Mail list logo
