On 03/23/17 07:53, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote:
>>> I'm not. I'm using QMP to change the index dynamically.
>>>
>> Wait, if you are already changing the "bootindex" property
>> dynamically (do I understand that right?)
>
> No, I'm not changing
On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote:
> > I'm not. I'm using QMP to change the index dynamically.
> >
> Wait, if you are already changing the "bootindex" property
> dynamically (do I understand that right?)
No, I'm not changing "bootindex" dynamically. I'm changing
On Wed, 2017-03-22 at 15:36 +0100, Laszlo Ersek wrote:
>
> To my knowledge, currently the bootindex properties cannot be changed
> dynamically (for example with monitor commands) after they have been
> specified on the QEMU command line.
Yes they can, via QMP:
{'execute': 'qom-get',
On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote:
>
> I'm generally opposed to the proposed implementation for this feature
> /
> use case; that is, the new "bootonceindex" device property.
>
> (1) My somewhat hand-waving counter-argument is simply the complexity
> /
> confusion that it
On 03/22/17 16:19, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 15:36 +0100, Laszlo Ersek wrote:
>>
>> To my knowledge, currently the bootindex properties cannot be changed
>> dynamically (for example with monitor commands) after they have been
>> specified on the QEMU command line.
>
> Yes
On 03/22/17 14:58, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote:
>>
>> I'm generally opposed to the proposed implementation for this feature
>> /
>> use case; that is, the new "bootonceindex" device property.
>>
>> (1) My somewhat hand-waving counter-argument is
On 03/22/17 10:00, Huttunen, Janne (Nokia - FI/Espoo) wrote:
> On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote:
>>
>> Understood---my question is how you would set up the alternate
>> boot order: is it something like "keep a button pressed while
>> turning on", or something written in
On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote:
>
> Understood---my question is how you would set up the alternate
> boot order: is it something like "keep a button pressed while
> turning on", or something written in NVRAM, or something else
> that is completely different?
In my case
- Original Message -
> From: "Janne Huttunen" <janne.huttu...@nokia.com>
> To: "Paolo Bonzini" <pbonz...@redhat.com>, "Gerd Hoffmann" <kra...@redhat.com>
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, March 22, 2017 7:36:54 AM
On Tue, 2017-03-21 at 18:55 +0100, Paolo Bonzini wrote:
>
> > Since real HW has this capability, there exist certain
> > auxiliary systems that are built on it. Having similar
> > semantics available in QEMU allows me to build a virtual
> > machine that works with these systems without modifying
Eric Blake writes:
> On 03/16/2017 04:46 AM, Janne Huttunen wrote:
>> On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
The short answer: emulating real hardware.
>>>
>>> Ok, that is reason enough.
>>>
>>> Adding bootonceindex everywhere doesn't look like the
On 15/03/2017 07:58, Janne Huttunen wrote:
>
> Since real HW has this capability, there exist certain
> auxiliary systems that are built on it. Having similar
> semantics available in QEMU allows me to build a virtual
> machine that works with these systems without modifying
> them in any way.
On 03/16/2017 04:46 AM, Janne Huttunen wrote:
> On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
>>>
>>> The short answer: emulating real hardware.
>>
>> Ok, that is reason enough.
>>
>> Adding bootonceindex everywhere doesn't look like the best plan to me
>> though. Possibly we can pimp
On Do, 2017-03-16 at 11:46 +0200, Janne Huttunen wrote:
> On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
> > >
> > > The short answer: emulating real hardware.
> >
> > Ok, that is reason enough.
> >
> > Adding bootonceindex everywhere doesn't look like the best plan to me
> > though.
On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
> >
> > The short answer: emulating real hardware.
>
> Ok, that is reason enough.
>
> Adding bootonceindex everywhere doesn't look like the best plan to me
> though. Possibly we can pimp up bootindex in a backward-compatible
> way?
>
Hi,
> The short answer: emulating real hardware.
>
> Since real HW has this capability, there exist certain
> auxiliary systems that are built on it. Having similar
> semantics available in QEMU allows me to build a virtual
> machine that works with these systems without modifying
> them in
14 Мар 2017 г. 19:58 пользователь "Gerd Hoffmann"
написал:
Hi,
> - Does this approach make sense? Any better ideas?
What is the use case?
Sometimes I'm wondering why we actually need the "once" thing. Looks
like people use it for installs, but I fail to see why. I
> > - Does this approach make sense? Any better ideas?
>
> What is the use case?
The short answer: emulating real hardware.
Since real HW has this capability, there exist certain
auxiliary systems that are built on it. Having similar
semantics available in QEMU allows me to build a virtual
Hi,
> - Does this approach make sense? Any better ideas?
What is the use case?
Sometimes I'm wondering why we actually need the "once" thing. Looks
like people use it for installs, but I fail to see why. I usually
configure my guests with hard disk as bootindex=1 and install media
(cdrom
This series implements a "bootonceindex" property for setting the boot
source priorities for the next boot only. In principle it is supposed
to do the same thing as the '-boot once=' argument but in a compatible
way with the 'bootindex' mechanism.
The basic idea is to have a second list that is
20 matches
Mail list logo