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 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
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?
>
> > - 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
The property works just like the "bootindex" property does, but uses
a separate list. When the list of boot devices is queried, the boot
once list is consulted first. The normal list is returned only if the
boot once list is empty.
Signed-off-by: Janne Huttunen <janne.huttu
Signed-off-by: Janne Huttunen <janne.huttu...@nokia.com>
---
hw/scsi/scsi-bus.c | 3 +++
include/hw/block/block.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 5940cb1..26e38ab 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi
Store the list head into the property structure. This allows the callback
functions to access the correct list even when there are multiple lists.
Signed-off-by: Janne Huttunen <janne.huttu...@nokia.com>
---
bootdevice.c | 36
1 file changed, 24 inse
Pass the list as a parameter instead of referencing it directly. This
is done so that a second list can be added in a later patch.
Signed-off-by: Janne Huttunen <janne.huttu...@nokia.com>
---
bootdevice.c | 49 +++--
1 file changed, 35 inse
to be possible.
- Any other suggestions/ideas/comments?
Janne Huttunen (6):
Re-factor bootdevice list handling, pt1.
Re-factor bootdevice list handling, pt2.
Add support for "bootonceindex" property.
Clear the boot once list after it has been used.
Support "bootonceindex&q
When the list is cleared, any attached properties are set to -1.
To do this, a reference to the property needs to be stored in
the list element.
Signed-off-by: Janne Huttunen <janne.huttu...@nokia.com>
---
bootdevice.c| 26 ++
hw/nvram/fw_cfg.c
Signed-off-by: Janne Huttunen <janne.huttu...@nokia.com>
---
hw/net/virtio-net.c| 3 +++
hw/virtio/virtio-pci.c | 2 ++
include/net/net.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index c321680..928b60b 100644
--- a/hw/net/
I came up with this version, it kind of reverses the logic of your
patch but reuses the _items function (renamed _length), please
see if it looks ok and possibly even works.
[sorry about the delay, I was out of office for a while]
Yes, your version works (both on paper and in practice). I'm
Hi!
I'm trying to run a Linux guest on top of QEMU (kvm). The only VGA
emulation that seems to give any kind of usable performance is the
vmware SVGA adapter, but that in turn is very unstable. It usually
freezes the guest display within a minute or two and starts printing
an error like
No, I think that can't happen, but it would be interesting to bisect
what the guest is doing exactly when this happens. The guest should
not move the next command pointer before if has written the command
entirely, this should be enough to guard against executing a partial
command. Unless
I see no way to tell whether the guest is currently in the middle of
writing a command. So it seems the only way to check is to peek the
first word in the fifo (which *is* written entirely before a NEXT_CMD
update) and look up the expected command length, and then check
whether enough data is
Here's an experiment for sanity checking the lengths and leaving
the command in the FIFO if it is not complete. It fixes the
problem for me (running it right now), but I agree that it's not
very elegant to look at :-/ .
And here's another version with couple of stupid bugs removed
(it
18 matches
Mail list logo
