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 "b
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
"bootonceindex
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', 'arguments':
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 intr
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 the
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 s
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 NVRAM,
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 the
- Original Message -
> From: "Janne Huttunen"
> To: "Paolo Bonzini" , "Gerd Hoffmann"
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, March 22, 2017 7:36:54 AM
> Subject: Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" propert
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 best plan to me
>>> t
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 up
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. Po
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?
> Someth
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 an
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 usually
configure my gu
> > - 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
m
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 o
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 so
20 matches
Mail list logo
