On 11.07.2017 16:23, Cornelia Huck wrote:
> On Tue, 11 Jul 2017 15:56:33 +0200
> Thomas Huth wrote:
>
>> The upcoming virtio-net driver needs to negotiate some features,
>> so we need the possibility to do this in the core virtio code.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> pc-bios/s390-ccw
Do the same thing to migration capabilities, just like what we did in
previous patch for migration parameters.
Signed-off-by: Peter Xu
---
migration/migration.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/migration/migration.c b/migration/migration.c
index fd00670..7e6
Export migration parameters to qdev properties. Then we can use, for
example:
-global migration.cpu-throttle-initial=xxx
To specify migration parameters during init.
One thing to mention is that, this usage should only be used for
debugging/testing purpose, and should never be used elsewhere.
We have merely all the stuff, but this one is missing. Add it in.
Am going to use this new helper for MigrationParameters fields, since
most of them are int64_t.
CC: Markus Armbruster
CC: Eduardo Habkost
CC: "Marc-André Lureau"
CC: Peter Xu
CC: Juan Quintela
CC: Marcel Apfelbaum
Signed-off-
"Dr. David Alan Gilbert (git)" writes:
> From: "Dr. David Alan Gilbert"
>
> The QMP query-vnc interfaces have gained a lot more information that
> the HMP interfaces hasn't got yet. Update it.
>
> Note the output format has changed, but this is HMP so that's OK.
>
> In particular, this now inclu
We have the MigrationState as QDev now (which seems crazy). Let's
continue to benefit.
This series is exporting all migration capabilities/params as global
parameters. Then we can do something like this:
qemu -global migration.postcopy-ram=true \
-global migration.max-bandwidth=4096
The
On 11.07.2017 20:23, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> v3.5: Added even register checks in the translator [thuth].
> ---
> target/s390x/helper.h | 6 +
> target/s390x/mem_helper.c | 310
> +
> target/s390x/tran
On Mon, 2017-07-03 at 19:20 +1000, David Gibson wrote:
> On Mon, Jul 03, 2017 at 01:18:38PM +1000, Suraj Jitindar Singh wrote:
> > On Fri, 2017-06-30 at 14:03 +1000, David Gibson wrote:
> > > On Thu, Jun 29, 2017 at 02:59:39PM +1000, Suraj Jitindar Singh
> > > wrote:
> > > > The Processor Compatibi
On 11/07/2017 17:47, Paolo Bonzini wrote:
On 11/07/2017 16:42, Kevin Wolf wrote:
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are
currently running the the 'pc' machine type. Please note that
future
versions
You can also apply this patch to go - I don't have an opinion on the
correct course of action though!
diff --git a/src/runtime/os_linux.go b/src/runtime/os_linux.go
index a6efc0e3d1..64218e3f7e 100644
--- a/src/runtime/os_linux.go
+++ b/src/runtime/os_linux.go
@@ -132,7 +132,8 @@ const (
Note that there is a go bug about this issue too:
https://github.com/golang/go/issues/20763
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1696353
Title:
golang binaries fail to start under linux-us
On 12/07/2017 8:51, Gerd Hoffmann wrote:
Hi,
Hi,
I think simply not having a default
machine type (as already suggested elsewhere in this thread) is the
best way to deal with this.
I would absolutely hate this. One of the nice things about qemu has
always been that 'qemu disk.img' is en
spapr_lmb_release() and spapr_core_release() call hotplug_handler_unplug()
which after a bunch of indirection calls spapr_memory_unplug() or
spapr_core_unplug(). But we already know which is the appropriate thing
to call here, so we can just fold it directly into the release function.
Once that's
Each DRC has three fields describing its state: isolation_state,
allocation_state and configured. At first this seems like a reasonable
representation, since its based directly on the PAPR defined
isolation-state and allocation-state indicators. However:
* Only a few combinations of the two fie
This function has two unused parameters - remove them.
It also sets awaiting_release on all paths, except one. On that path
setting it is harmless, since it will be immediately cleared by
spapr_drc_release(). So factor it out of the if statements.
Signed-off-by: David Gibson
---
hw/ppc/spapr.
The awaiting_allocation flag in the DRC was introduced by aab9913
"spapr_drc: Prevent detach racing against attach for CPU DR", allegedly to
prevent a guest crash on racing attach and detach. Except.. information
from the BZ actually suggests a qemu crash, not a guest crash. And there
shouldn't b
From: Laurent Vivier
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Be
This sixth set of DRC cleanup patches is a complete rework of DRC
state management. We stop tracking some unnecessary things, and
change the basic state representation to a simpler and more robust
model.
Many of the patches in this set "break" migration from earlier git
snapshots, but not from an
Most of the time, the state of a DRC object is contained in the single
'state' variable. However, during the transition from UNISOLATE to
CONFIGURED state requires multiple calls to the ibm,configure-connector
RTAS call to retrieve the device tree for the attached device. We need
some extra state
'awaiting_release' indicates that the host has requested an unplug of the
device attached to the DRC, but the guest has not (yet) put the device
into a state where it is safe to complete removal.
1. Rename it to 'unplug_requested' which to me at least is clearer
2. Remove the ->release_pending()
According to PAPR, the DR-indicator should only be valid for physical DRCs,
not logical DRCs. At the moment we implement it for all DRCs, so restrict
it to physical ones only.
We move the state to the physical DRC subclass, which means adding some
QOM boilerplate to handle the newly distinct type
Hi,
> > I think simply not having a default
> > machine type (as already suggested elsewhere in this thread) is the
> > best way to deal with this.
>
> I would absolutely hate this. One of the nice things about qemu has
> always been that 'qemu disk.img' is enough to start a simple VM.
Well, n
On 11.07.2017 20:55, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> same as Thomas previous patch. this file had no entry in MAINTAINERS.
>
> atomic_template.h => accel/tcg/atomic_template.h | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename atomic_te
On 07/11/2017 11:21 AM, Richard Henderson wrote:
I am in the process of trying to run the gcc testsuite with -mtbm,
with and without the patchset, to see (1) if the new insns get used
and (2) that they run ok.
FWIW, make check-gcc RUNTESTFLAGS='--target_board=unix/-mtbm execute.exp' shows
204
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, July 11, 2017 6:21 PM
> To: Bharat Bhushan ; Auger Eric
> ; eric.auger@gmail.com;
> peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> qemu-...@nongnu.org;
On Tue, Jul 04, 2017 at 07:49:15PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> When we issue a cancel and clean up the RDMA channel
> send a CONTROL_ERROR to get the destination to quit.
>
> The rdma_cleanup code waits for the event to come back
> from the rdm
On Tue, Jul 04, 2017 at 07:49:14PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> control_desc[] is an array of strings that correspond to a
> series of message types; they're used only for error messages, but if
> the message type is seriously broken then we coul
On Tue, Jul 04, 2017 at 07:49:12PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Closing the file before exit on a failure allows
> the source to cleanup better, especially with RDMA.
>
> Partial fix for https://bugs.launchpad.net/qemu/+bug/1545052
In above bug
On Tue, Jul 04, 2017 at 07:49:11PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Fix a race where the destination might try and send the source a
> WRID_READY before the source has done a post-recv for it.
>
> rdma_post_recv has to happen after the qp exists, an
On Mon, 07/10 15:55, Stefan Hajnoczi wrote:
> On Wed, Jul 05, 2017 at 09:36:31PM +0800, Fam Zheng wrote:
> > +static bool nvme_identify(BlockDriverState *bs, int namespace, Error
> > **errp)
> > +{
> > +BDRVNVMeState *s = bs->opaque;
> > +uint8_t *resp;
> > +int r;
> > +uint64_t io
Eric,
I have submitted patch version 5 to fix the issue that you are concerned,
hope you can have a review this series of patches, thanks.
Result: 250 2.6.0 <1499825297-20335-1-git-send-email-gengdong...@huawei.com>
[InternalId=34134279] Queued mail for delivery
Result: 250 2.6.0 <1499825297-2
Applied to ppc-for-2.10, though I'm going to make some minor followup
cleanups.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozl
This implements APEI GHES Table by passing the error CPER info
to the guest via a fw_cfg_blob. After a CPER info is recorded, an
SEA(Synchronous External Abort)/SEI(SError Interrupt) exception
will be injected into the guest OS.
Below is the table layout, the max number of error soure is 11,
which
In the armv8 platform, the mainly hardware error source are ARMv8
SEA/SEI/GSIV. For the ARMv8 SEA/SEI, the KVM or host kernel will signal SIGBUS
or use other interface to notify user space, such as Qemu. After Qemu gets
the notification, it will record the CPER and inject the SEA/SEI to KVM. this
s
(1) Add related APEI/HEST table structures and macros, these
definition refer to ACPI 6.1 and UEFI 2.6 spec.
(2) Add generic error status block and CPER memory section
definition, user space only handle memory section errors.
Signed-off-by: Dongjiu Geng
---
thanks Laszlo and Michael's re
Add CONFIG_ACPI_APEI configuration in the Makefile and
enable it in the arm-softmmu.mak
Signed-off-by: Dongjiu Geng
---
thanks a lot Laszlo's review and comments:
change since v4:
(1) fix email threading in this series is incorrect issue
change since v3:
(1) change name to "CONFIG_ACPI_APEI" f
On Tue, 07/11 12:28, Paolo Bonzini wrote:
> On 11/07/2017 12:05, Stefan Hajnoczi wrote:
> > On Mon, Jul 10, 2017 at 05:08:56PM +0200, Paolo Bonzini wrote:
> >> On 10/07/2017 17:07, Stefan Hajnoczi wrote:
> >>> On Wed, Jul 05, 2017 at 09:36:32PM +0800, Fam Zheng wrote:
> Allow block driver to m
On 07/10/2017 05:27 PM, Philippe Mathieu-Daudé wrote:
For the record, what is the os version?
Because this doesn't happen here for Centos7.
Oops true I forgot to log this info in the commit.
This happens on debian/powerpc Jessie, using GCC 4.9.2-10
Thanks. Queued to tcg-next.
r~
qemu call kvm_get_vcpu_events, and kernel return sipi_vector always 0,
never valid when reporting to user space. But qemu call kvm_put_vcpu_events
will make sipi_vector in kernel be 0. This will accidently modify sipi_vector
when sipi_vector in kernel is not 0.
Signed-off-by: Peng Hao
Reviewed-by
On 07/10/2017 01:57 PM, Emilio G. Cota wrote:
What I would prefer to do is generalize tb->cflags. Those values *do*
affect how we compile the TB, and yet we don't take them into account. So I
think it would be a good idea to feed that into the TB hash.
I'm having trouble seeing how this could
On Tue, Jul 11, 2017 at 04:43:50PM -0700, Ben Warren wrote:
> Hi Laszlo,
>
>
> On Jul 11, 2017, at 3:13 PM, Laszlo Ersek wrote:
>
> On 07/11/17 22:42, Peter Maydell wrote:
>
> On 11 July 2017 at 20:10, Michael S. Tsirkin wrote:
>
> On Tue, Jul 11, 2017 at 05:49:07
On Mon, 10 Jul 2017, Anthony PERARD wrote:
> Hi Stefano,
>
> Looks like this patch can be applied.
Thank you for pointing it out to me, because this email has
inexplicably disappeared from my inbox. I have now marked it
appropriately to be committed.
>
> On Fri, Mar 24, 2017 at 01:40:25PM +
On Mon, 10 Jul 2017, Peter Maydell wrote:
> On 10 July 2017 at 17:14, Paolo Bonzini wrote:
> > On 10/07/2017 17:49, Peter Maydell wrote:
> >> On 5 July 2017 at 08:14, Paolo Bonzini wrote:
> >>> This will be useful when the functions are called, early in the configure
> >>> process, to filter out
On Tue, 11 Jul 2017, Paolo Bonzini wrote:
> On 11/07/2017 11:53, Peter Maydell wrote:
> > On 11 July 2017 at 09:23, Paolo Bonzini wrote:
> >> While ARM could present the xenpv machine, it does not and trying to enable
> >> it breaks compilation.
> >>
> >> Fixes: 3b6b75506de44c5070639943c30a0ad5850
Hi
On Tue, Jul 11, 2017 at 10:23 PM Laszlo Ersek wrote:
> On 07/11/17 12:30, Marc-André Lureau wrote:
> > Add vmcoreinfo ELF note if vmcoreinfo device is ready.
> >
> > To help the python script, add a little global vmcoreinfo_gdb
> > structure, that is populated with vmcoreinfo_gdb_update().
>
On Tue, 07/11 16:35, Pavel Butsykin wrote:
> On 11.07.2017 16:14, no-re...@patchew.org wrote:
> > Hi,
> >
> > This series failed build test on s390x host. Please find the details below.
> >
> > Type: series
> > Subject: [Qemu-devel] [PATCH v4 0/4] Add shrink image for qcow2
> > Message-id: 201707
Hi Laszlo,
> On Jul 11, 2017, at 3:13 PM, Laszlo Ersek wrote:
>
> On 07/11/17 22:42, Peter Maydell wrote:
>> On 11 July 2017 at 20:10, Michael S. Tsirkin wrote:
>>> On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote:
The good news is it's not aarch64-specific. I just hit this on
Peter Maydell, on lun. 05 juin 2017 17:19:35 +0100, wrote:
> The code in sosendoob() assumes that slirp_send() always
> succeeds, but it might return an OS error code (for instance
> if the other end has disconnected). Catch these and return
> the caller either -1 on error or the number of urgent b
Peter Maydell, on lun. 05 juin 2017 17:19:36 +0100, wrote:
> diff --git a/slirp/socket.c b/slirp/socket.c
> index a17caa9..84cf13a 100644
> --- a/slirp/socket.c
> +++ b/slirp/socket.c
> @@ -404,7 +404,14 @@ sowrite(struct socket *so)
> DEBUG_ARG("so = %p", so);
>
> if (so->so_urgc) {
Peter Maydell, on dim. 09 juil. 2017 18:54:22 +0100, wrote:
> In a fork_exec() error path we try to closesocket(s) when s might
> be a negative number because the thing that failed was the
> qemu_socket() call. Add a guard so we don't do this.
>
> (Spotted by Coverity: CID 1005727 issue 1 of 2.)
On 07/11/17 22:42, Peter Maydell wrote:
> On 11 July 2017 at 20:10, Michael S. Tsirkin wrote:
>> On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote:
>>> The good news is it's not aarch64-specific. I just hit this on
>>> a build on x86_64 host, gcc, debug build:
>>>
>>> GTESTER check-q
On 11/07/17 18:59, Mark Cave-Ayland wrote:
> On 11/07/17 16:57, Michael S. Tsirkin wrote:
>
>> On Tue, Jul 11, 2017 at 06:51:50PM +0300, Marcel Apfelbaum wrote:
>>> On 11/07/2017 18:31, Michael S. Tsirkin wrote:
On Fri, Jul 07, 2017 at 08:43:59AM +0100, Mark Cave-Ayland wrote:
> For some
This switches the sun4u model to being much closer to a real Ultra 5.
Since the existing code previously bypassed the PCI bridge interrupt
swizzling, reorganise the interrupt mapping functions so that
pci_pbm_map_irq() is used by the PCI bridges and pci_apb_map_irq() is
used by the PCI host bridge
Signed-off-by: Mark Cave-Ayland
---
hw/pci-host/apb.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/pci-host/apb.c b/hw/pci-host/apb.c
index 622c341..5ad7678 100644
--- a/hw/pci-host/apb.c
+++ b/hw/pci-host/apb.c
@@ -561,7 +561,7 @@ static uint64_t apb_config_rea
The aim of this patchset is to bring the sun4u machine in line with a real
Ultra 5
in order to resolve issues related to PCI bridge windows and interrupt routing.
The majority of the changes are designed to accommodate the simba PCI bridges on
the root PCI bus, moving the on-board devices behind
In order to wire up the ebus PCI address spaces differently then we need
access to the underlying PCIDevice.
Signed-off-by: Mark Cave-Ayland
---
hw/sparc64/sun4u.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index 69f565d
As we move towards a real Ultra 5 machine, allow only a single NIC
to be instantiated with the legacy net options. More devices can
be added with the new -netdev and -device options if required.
Signed-off-by: Mark Cave-Ayland
---
hw/sparc64/sun4u.c |8 +---
1 file changed, 5 insertions(
Signed-off-by: Mark Cave-Ayland
---
hw/sparc64/sun4u.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index 7738856..8932be9 100644
--- a/hw/sparc64/sun4u.c
+++ b/hw/sparc64/sun4u.c
@@ -512,7 +512,15 @@ static void sun4uv_in
To allow future changes to the sun4u PCI topology.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Acked-By: Artyom Tarasenko
---
hw/sparc64/sun4u.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index
Rather than referring to the PCI busses as bus2 and bus3, refer to them as
busA and busB as per the documentation. Also replace the long bus names with
the shorter pciA and pciB aliases (to make it easier to attach additional
devices to either from the command line).
Signed-off-by: Mark Cave-Aylan
As future sun4u PCI topologies place the ebus containing the in-built devices
behind a PCI bridge, add a busA property to the PBM PCI bridge that is then
used to allow IO accesses by default.
This allows early fw_cfg/NVRAM/serial access to occur even before OpenBIOS
has had a chance to configure t
Add a new slot_reserved_mask bitmask to PCIBus indicating whether or not each
PCI slot on the bus is reserved. Ensure that it is initialised to zero to
maintain the existing behaviour that all slots are available by default, and
add the additional check with appropriate error reporting to
do_pci_re
For some machines it is impossible to plug devices into a particular PCI bus
slot, e.g. for a real Ultra 5 there are 2 PCI bridges attached to the root
bus behind which all devices must be plugged. Ignoring this rule will cause
problems with interrupt routing since the interrupt numbers are calcula
Also touch up the logic in do_pci_register_device() accordingly.
Signed-off-by: Mark Cave-Ayland
---
hw/pci/pci.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 0c6f74a..04e6edb 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
(off-topic)
On 07/11/17 22:49, Peter Maydell wrote:
> On 11 July 2017 at 21:26, Mark Cave-Ayland
> wrote:
>> On 11/07/17 21:18, Michael S. Tsirkin wrote:
>>
>>> Multi-line comments also should formatted
>>>
>>> /*
>>> * like
>>> * this
>>> */
>>>
>>> not
>>>
>>> /* like
>>> * this */
>>>
>>
>
These are general purpose bit manipulation instructions akin
to the BMI1 and BMI2 instructions. This is an AMD extension
and uses the XOP instruction prefix.
I am in the process of trying to run the gcc testsuite with -mtbm,
with and without the patchset, to see (1) if the new insns get used
and
Signed-off-by: Richard Henderson
---
target/i386/translate.c | 46 --
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/target/i386/translate.c b/target/i386/translate.c
index ed3b896..6082db2 100644
--- a/target/i386/translate.c
+++ b/tar
Reported-by: Ricardo Ribalda Delgado
Signed-off-by: Richard Henderson
---
target/i386/cc_helper_template.h | 18 ++
target/i386/cpu.h| 7 ++-
target/i386/cc_helper.c | 28 +++--
target/i386/cpu.c| 3 +-
target/i386/translate.c | 123
On Tue, 2017-07-11 at 15:52 +0200, Cédric Le Goater wrote:
>
> > Just as we could build a POWER9 with XICS in qemu, we could build a
> > POWER8 with XIVE.
>
> That might be the case with a POWER9 running in POWER8 compat mode.
> I need to check.
Yes. In "compat" mode (or more generally if the
On 07/11/2017 03:40 PM, Peter Maydell wrote:
>>>
>>> The problem is you can only bail while you're in the parent
>>> before forking. Once you've started the child there's no
>>> mechanism for dealing with failure.
>>
>> Well, you can always exit the child before anything worse can happen.
>
> You
On Tue, Jul 11, 2017 at 09:02:12PM +0100, Mark Cave-Ayland wrote:
> When looking to instantiate a TYPE_FW_CFG_MEM or TYPE_FW_CFG_IO device to be
> able to wire it up differently, it is much more convenient for the caller to
> instantiate the device and have the fw_cfg default files already preloade
On 07/11/2017 09:20 AM, Alex Bennée wrote:
Richard Henderson writes:
On 07/11/2017 07:59 AM, Alex Bennée wrote:
if (use_goto_tb(s, dest)) {
tcg_gen_goto_tb(n);
gen_set_pc_im(s, dest);
tcg_gen_exit_tb((uintptr_t)s->tb + n);
+s->is_jmp = DISAS_TB
On 11 July 2017 at 21:58, Eduardo Habkost wrote:
> On Tue, Jul 11, 2017 at 09:49:30PM +0100, Peter Maydell wrote:
>> It's basically GNU coding standard style vs Linux kernel style;
>> there's a mix because some contributors are more used to working
>> on the kernel, and some more used to working w
On Tue, Jul 11, 2017 at 09:49:30PM +0100, Peter Maydell wrote:
> On 11 July 2017 at 21:26, Mark Cave-Ayland
> wrote:
> > On 11/07/17 21:18, Michael S. Tsirkin wrote:
> >
> >> Multi-line comments also should formatted
> >>
> >> /*
> >> * like
> >> * this
> >> */
> >>
> >> not
> >>
> >> /* like
>
On 11 July 2017 at 21:42, Philippe Mathieu-Daudé wrote:
> Hi Peter,
>
> There is probably no need yet, but we could model a generic APB slave with
> this code, as an overlapping subregion (device top 0x30 bytes).
>
> For now only PID0 differs, but since all ID are 8bit the device could even
> inst
On 11 July 2017 at 21:26, Mark Cave-Ayland
wrote:
> On 11/07/17 21:18, Michael S. Tsirkin wrote:
>
>> Multi-line comments also should formatted
>>
>> /*
>> * like
>> * this
>> */
>>
>> not
>>
>> /* like
>> * this */
>>
>
> Interesting, I never knew there was a preferred format for comments (I
On 07/11/2017 03:36 PM, Laszlo Ersek wrote:
On 07/11/17 16:31, Stefan Berger wrote:
This patch adds a description of the current TPM support in QEMU
to the specs.
Several public specs are referenced via their landing page on the
trustedcomputinggroup.org website.
Signed-off-by: Stefan Berger
I no longer have a setup to test this so I can only say to close it.
On Jul 11, 2017 4:15 PM, "Thomas Huth" <1095...@bugs.launchpad.net>
wrote:
> Can you still reproduce this problem wit the latest release of QEMU
> (currently version 2.9.0), or could we close this bug nowadays?
>
> ** Changed in
Hi Peter,
There is probably no need yet, but we could model a generic APB slave
with this code, as an overlapping subregion (device top 0x30 bytes).
For now only PID0 differs, but since all ID are 8bit the device could
even instantiate the subregion with some u64 PID, 32 CID args.
(thinking
On 11 July 2017 at 20:10, Michael S. Tsirkin wrote:
> On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote:
>> The good news is it's not aarch64-specific. I just hit this on
>> a build on x86_64 host, gcc, debug build:
>>
>> GTESTER check-qtest-x86_64
>> **
>> ERROR:/home/petmay01/linar
On 11 July 2017 at 20:08, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> [cc'd Eric as the sort of person
>>
>> On 11 July 2017 at 17:29, Dr. David Alan Gilbert wrote:
>> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> >> In a fork_exec() error path we
On 11 July 2017 at 19:46, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> sosendoob() can return a failure code, but all its callers ignore it.
>> This is OK in sbappend(), as the comment there states -- we will try
>> again later in sowrite(). Add a (void) cas
On Tue, Jul 11, 2017 at 09:26:22PM +0100, Mark Cave-Ayland wrote:
> On 11/07/17 21:18, Michael S. Tsirkin wrote:
>
> > Multi-line comments also should formatted
> >
> > /*
> > * like
> > * this
> > */
> >
> > not
> >
> > /* like
> > * this */
> >
>
> Interesting, I never knew there was a
On 11/07/17 21:18, Michael S. Tsirkin wrote:
> Multi-line comments also should formatted
>
> /*
> * like
> * this
> */
>
> not
>
> /* like
> * this */
>
Interesting, I never knew there was a preferred format for comments (I
see both styles throughout the codebase).
FWIW it's probably wor
On 07/11/17 12:30, Marc-André Lureau wrote:
> v3: from Laszlo review
> - change vmcoreinfo offset to 36
> - reset err to null after report
> - use PRIu32
> - change name_size and desc_size against MAX_VMCOREINFO_SIZE
> - python code simplification
> - check boundaries of blocks in phys_memory_read
On 07/11/17 12:30, Marc-André Lureau wrote:
> Add vmcoreinfo ELF note if vmcoreinfo device is ready.
>
> To help the python script, add a little global vmcoreinfo_gdb
> structure, that is populated with vmcoreinfo_gdb_update().
>
> Signed-off-by: Marc-André Lureau
> ---
> scripts/dump-guest-mem
On Tue, Jul 11, 2017 at 05:10:59PM -0300, Eduardo Habkost wrote:
> On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote:
> > This will enable the fw_cfg device to be placed anywhere within the QOM tree
> > regardless of its machine location.
> >
> > Note that we also add a comment to d
Can you still reproduce this problem wit the latest release of QEMU
(currently version 2.9.0) and macOS, or could we close this bug
nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
Can you still reproduce this problem wit the latest release of QEMU
(currently version 2.9.0), or could we close this bug nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Can you still reproduce this problem wit the latest release of QEMU
(currently version 2.9.0), or could we close this bug nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 11/07/17 21:10, Eduardo Habkost wrote:
> On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote:
>> This will enable the fw_cfg device to be placed anywhere within the QOM tree
>> regardless of its machine location.
>>
>> Note that we also add a comment to document the behaviour that
Triaging old bug tickets ... Can you still reproduce this problem wit
the latest release of QEMU (currently version 2.9.0), or could we close
this bug nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml,
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1095857
Title:
incorrect handling of [r32] address (long mode)
Status in QEMU:
Incomplete
Bug
On Tue, Jul 11, 2017 at 10:04:43PM +0200, Laszlo Ersek wrote:
[...]
> > +lines = g_strsplit((char *)vmci, "\n", -1);
> > +for (i = 0; lines[i]; i++) {
> > +if (g_str_has_prefix(lines[i], "NUMBER(phys_base)=")) {
> > +if (qemu_strtou64(lines[i] + 18, NULL, 16,
> > +
On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote:
> This will enable the fw_cfg device to be placed anywhere within the QOM tree
> regardless of its machine location.
>
> Note that we also add a comment to document the behaviour that we return NULL
> to
> indicate failure where ei
Is there still something left to do here, or could we close this bug
nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1089006
Title:
Qem
On 07/11/17 12:30, Marc-André Lureau wrote:
> Read the vmcoreinfo ELF PT_NOTE from guest memory when vmcoreinfo
> device provides the location, and write it as an ELF note in the dump.
>
> There are now 2 possible sources of phys_base information.
>
> (1) arch guessed value from cpu_get_dump_info
Closing according to comment #2 and #3
** Changed in: qemu
Status: New => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1089281
Title:
kvm crash when writing on disk
Status in QE
When looking to instantiate a TYPE_FW_CFG_MEM or TYPE_FW_CFG_IO device to be
able to wire it up differently, it is much more convenient for the caller to
instantiate the device and have the fw_cfg default files already preloaded
during realize.
Move fw_cfg_init1() to the end of both the fw_cfg_mem
By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
for the internal MemoryRegion fields to be mapped by name for boards that wish
to wire up the fw_cfg device themselves.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Laszlo Ersek
---
hw/nvram/fw_cfg.c | 49 +-
1 - 100 of 525 matches
Mail list logo
