Peter Maydell writes:
> On 11 June 2018 at 08:56, Markus Armbruster wrote:
>> You're not printing $strchrnul like we print other configuration
>> results. Hmm, we're not printing several of them. Question for
>> maintainers (MAINTAINERS doesn't have any, so I'm cc'ing the top three
>> coughed
Keno Fischer writes:
> strchrnul is a GNU extension and thus unavailable on a number of targets.
> In the review for a commit removing strchrnul from 9p, I was asked to
> create a qemu_strchrnul helper to factor out this functionality.
> Do so, and use it in a number of other places in the code
On 2018年06月13日 12:24, Samudrala, Sridhar wrote:
On 6/12/2018 7:38 PM, Jason Wang wrote:
On 2018年06月12日 19:54, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both
These files can not be executed on the host, so they should not be
marked as executable.
Signed-off-by: Thomas Huth
---
block/blkreplay.c | 0
pc-bios/hppa-firmware.img | Bin
pc-bios/palcode-clipper| Bin
pc-bios/u-boot-sam460-20100605.bin | Bin
Instead of repeating the same text for both options, let's rather change
the '-machine accel' documentation to point to the preferred '-accel' option
instead.
And in the documenation of the -accel option, make it clear that you can
use colons to specify multiple accelerators.
Signed-off-by:
The preferred way to select the KVM accelerator is to use "-accel kvm"
these days, so let's be consistent in our documentation and help texts.
Signed-off-by: Thomas Huth
---
docs/COLO-FT.txt | 8
docs/can.txt | 4 ++--
We've got three ways of enabling an accelerator: -machine accel=xyz,
-accel xyz and -enable-xyz. For new QEMU users, this must be very
confusing ("Which one do I have to use? Is there a difference between
the options?"). While -enable-kvm was useful in the past, there is no
real good reason for
The current state of the accelerator options is quite messy: There are
three ways of enabling an accelerator (-machine accel=xyz, -accel xyz
and -enable-xyz) and this can be very confusing for the users. This
patch series now tries to standardize our documentation and examples
on the preferred
We've got a separate option to configure the accelerator nowadays.
Use it in the source and examples to demonstrate that this is the
preferred way of setting this option now.
Signed-off-by: Thomas Huth
---
qemu-doc.texi | 3 +--
qemu-options.hx | 2 +-
On Fri, May 18, 2018 at 06:44:04PM +0200, Cédric Le Goater wrote:
> This proposal moves all the related IRQ routines of the sPAPR machine
> behind a class interface to prepare for future changes in the IRQ
> controller model. First of which is a reorganization of the IRQ number
> space layout and
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1195012
Title:
x86_64 and
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1190525
Title:
fdisk
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1013241
Title:
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1446726
Title:
qemu
On Tue, Jun 05, 2018 at 08:31:49AM +0200, Cédric Le Goater wrote:
> On 06/05/2018 05:44 AM, David Gibson wrote:
> > On Sat, May 26, 2018 at 11:40:23AM +0200, Greg Kurz wrote:
> >> On Fri, 18 May 2018 18:44:03 +0200
> >> Cédric Le Goater wrote:
> >>
> >>> PCI LSIs are today allocated one by one
On 6/12/2018 7:38 PM, Jason Wang wrote:
On 2018年06月12日 19:54, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy
On Tue, Jun 05, 2018 at 08:41:13AM +0200, Cédric Le Goater wrote:
> On 06/05/2018 05:34 AM, David Gibson wrote:
> > On Mon, May 28, 2018 at 09:06:12AM +0200, Cédric Le Goater wrote:
> >> On 05/28/2018 08:17 AM, Thomas Huth wrote:
> >>> On 25.05.2018 16:02, Greg Kurz wrote:
> On Fri, 18 May
On Wed, Jun 06, 2018 at 07:35:28PM +0200, BALATON Zoltan wrote:
> On Wed, 6 Jun 2018, Philippe Mathieu-Daudé wrote:
> > On 06/06/2018 10:31 AM, BALATON Zoltan wrote:
> > > Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
> > > of day is implemented. Setting time and RTC alarm
On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> On 12 June 2018 at 07:24, Peter Xu wrote:
> > For example, I wanted to compile QEMU once and install it on multiple
> > systems. What would be the suggested way to do so?
>
> For this, I would recommend using whatever the
On Tue, Jun 12, 2018 at 23:15:49 -0400, Yaowei Bai wrote:
> Signed-off-by: Yaowei Bai
> ---
> docs/devel/tracing.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt
> index 07abbb3..6ab32cc 100644
> ---
strchrnul is a GNU extension and thus unavailable on a number of targets.
In the review for a commit removing strchrnul from 9p, I was asked to
create a qemu_strchrnul helper to factor out this functionality.
Do so, and use it in a number of other places in the code base that inlined
the
On Tue, Jun 12, 2018 at 12:53:36AM -0700, Liviu Ionescu wrote:
> On 12 June 2018 at 10:44:09, Peter Xu (pet...@redhat.com) wrote:
>
> > But it'll still be good if we can have a single package to play around
> > with. If there is no known way to do, we can try to figure a way out.
>
> you can
On Tue, Jun 12, 2018 at 01:29:32PM +0200, Laszlo Ersek wrote:
> Hi Fam,
>
> On 06/12/18 08:41, Fam Zheng wrote:
> > On Tue, 06/12 14:24, Peter Xu wrote:
> >> Hi,
> >>
> >> For example, I wanted to compile QEMU once and install it on multiple
> >> systems. What would be the suggested way to do
On Mon, Jun 11, 2018 at 13:56:32 +0100, Peter Maydell wrote:
> typedef struct CPUIOTLBEntry {
> +/*
> + * @addr contains:
> + * - in the lower TARGET_PAGE_BITS, a physical section number
> + * - with the lower TARGET_PAGE_BITS masked off, an offset which
> + *must be
Signed-off-by: Yaowei Bai
---
docs/devel/tracing.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt
index 07abbb3..6ab32cc 100644
--- a/docs/devel/tracing.txt
+++ b/docs/devel/tracing.txt
@@ -18,7 +18,7 @@ for debugging,
On Tue, Jun 12, 2018 at 09:05:25PM +0200, Eric Auger wrote:
> When an IOMMUMemoryRegion is in front of a virtio device,
> address_space_cache_init does not set cache->ptr as the memory
> region is not RAM. However when the device performs an access,
> we end up in glue() which performs the
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180613015641.5667-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH v4b 00/18] target/arm: SVE instructions, part 2
=== TEST SCRIPT BEGIN ===
#!/bin/bash
On 2018年06月13日 08:20, Samudrala, Sridhar wrote:
On 6/12/2018 4:54 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a
On 2018年06月12日 19:54, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy guest without
support for the feature
On 2018年06月13日 10:26, Philippe Mathieu-Daudé wrote:
Hi Jason,
On 06/12/2018 11:18 PM, Jason Wang wrote:
On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
Cc'ing Jason who is also listed as co-maintainer:
./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
Dmitry Fleytman
On 2018/6/12 20:17, Paolo Bonzini wrote:
> On 16/05/2018 11:18, Shannon Zhao wrote:
>> According to KVM commit 75d61fbc, it needs to delete the slot before
>> changing the KVM_MEM_READONLY flag. But QEMU commit 235e8982 only check
>> whether KVM_MEM_READONLY flag is set instead of changing. It
We always call it with the same fields of the struct we always pass.
We can split this out later if we really wind up needing to.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/block/qcow2-bitmap.c
Hi Jason,
On 06/12/2018 11:18 PM, Jason Wang wrote:
> On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
>> Cc'ing Jason who is also listed as co-maintainer:
>>
>> ./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
>> Dmitry Fleytman (maintainer:e1000e)
>> Jason Wang (odd
Presently, an image with IN_USE bitmaps cannot be loaded as RO.
In preparation for changing that, IN_USE bitmaps ought to create an
error on reload instead of being skipped.
While we're here, update the function to work with two new facts:
- All bm_list entries will have a BdrvDirtyBitmap
Allow qemu-img to show information about bitmaps stored in qcow2 images.
v2:
- Remove bitmap manipulation command in favor of a part 2 series later
- Responded to much of Vladimir's feedback (Thank you!);
- In particular, make sure IN_USE bitmaps cannot be remounted RW.
- Fixed semantics of
Similarly to the last patch, track the extra_data_size field that we read.
We do reject anything other than zero, but if this restriction is lifted
in the future, we'll need to update the _info field, so loosen this now.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 4 +++-
1 file
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 25 +++
target/arm/sve_helper.c| 41 +++
target/arm/translate-sve.c | 144 +
target/arm/sve.decode | 26 +++
4 files changed, 236
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 14
target/arm/helper.h| 19 +++
target/arm/translate-sve.c | 42 +++
target/arm/vec_helper.c| 69 ++
Add functions for querying the basic information inside of bitmaps.
Restructure the bitmaps flags masks to facilitate providing a list of
flags belonging to the bitmap(s) being queried.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 86 ++--
On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
Cc'ing Jason who is also listed as co-maintainer:
./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
Dmitry Fleytman (maintainer:e1000e)
Jason Wang (odd fixer:Network devices)
On 06/12/2018 03:43 PM, Jan Kiszka wrote:
On
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 31
target/arm/translate-sve.c | 99 ++
target/arm/sve.decode | 8 +++
4 files changed, 140 insertions(+)
diff --git
For bitmaps that we succeeded in loading, we can cache a reference
to that object. This will let us iterate over the more convenient
form of in-memory bitmaps for qemu-img bitmap manipulation tools.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff
Add some of the necessary scaffolding for reporting bitmap information.
Signed-off-by: John Snow
---
qapi/block-core.json | 64 +++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 14
target/arm/translate-sve.c | 133 +
target/arm/sve.decode | 27
4 files changed, 176 insertions(+)
diff
We only have one type of persistent bitmap right now, but I'd like the
qemu-img tool to be able to give good diagnostic information if it sees
an unknown/unsupported type.
We do enforce it to be the dirty tracking type in check_dir_entry, but
I wanted positive affirmation of the type in the
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 18 +++
target/arm/sve_helper.c| 248 +
target/arm/translate-sve.c | 106
target/arm/sve.decode | 19 +++
4 files changed, 391
We don't need to re-read this list every time, exactly. We can keep it cached
and delete our copy when we flush to disk.
Because we don't try to flush bitmaps on close if there's nothing to flush,
add a new conditional to delete the state anyway for a clean exit.
Signed-off-by: John Snow
---
For the purposes of qemu-img manipulation and querying of bitmaps, load
bitmaps that are "in use" -- if the image is read only. This will allow
us to diagnose problems with this flag using the qemu-img tool.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 32 +++-
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 9 +++
target/arm/sve_helper.c| 55 ++
target/arm/translate-sve.c | 2 ++
target/arm/sve.decode | 6 +
4 files changed, 72 insertions(+)
diff
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 44 +++
target/arm/sve_helper.c| 88 ++
target/arm/translate-sve.c | 66
target/arm/sve.decode | 23 ++
Instead of always setting IN_USE, do this conditionally based on
whether or not the bitmap is read-only. Eliminate the two-pass
processing and move the second loop to the failure case.
This will allow us to show the flags exactly as they appear
on-disk for bitmaps in `qemu-img info`.
On Tue, Jun 12, 2018 at 07:12:47PM +0800, Wei Wang wrote:
[...]
> Hi Peter,
>
> Thanks for the review. We just got a little accident in the kernel part,
> which may cause some modifications to the QEMU side interfaces. So I will
> implement a new version and let you review in v9 patches.
No
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 14 +
target/arm/sve_helper.c| 41 +++---
target/arm/translate-sve.c | 38 +++
target/arm/sve.decode | 7 +++
4
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 3 +++
target/arm/sve_helper.c| 34 ++
target/arm/translate-sve.c | 12
target/arm/sve.decode | 6 ++
4 files changed, 55 insertions(+)
diff
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 12 ++
target/arm/translate-sve.c | 328 +
target/arm/sve.decode | 20 +++
4 files changed, 362 insertions(+)
diff --git
Hello all,
I am working on developing a "modified" record-replay mechanism for
recording and replaying disk and network events along with VMEntry events.
I have managed to identify the "correct" points where I am going to record
the disk and the network events. But I am not quite sure at which
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-sve.c | 37 +
target/arm/sve.decode | 8
2 files changed, 45 insertions(+)
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 6 +
target/arm/sve_helper.c| 290 +
target/arm/translate-sve.c | 120 +++
target/arm/sve.decode | 18 +++
4 files changed, 434 insertions(+)
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 115 +++
target/arm/sve_helper.c| 187 +
target/arm/translate-sve.c | 91 ++
target/arm/sve.decode | 24 +
4 files
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 ++
target/arm/sve_helper.c| 37 +
target/arm/translate-sve.c | 13 +
target/arm/sve.decode | 3 +++
4 files changed, 55 insertions(+)
diff
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 15
target/arm/sve_helper.c| 72
target/arm/translate-sve.c | 75 ++
target/arm/sve.decode | 10 +
4 files
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-sve.c | 19 +++
target/arm/sve.decode | 6 ++
2 files changed, 25 insertions(+)
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index feb4c09f1b..eed59524a9
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 23 +++
target/arm/sve_helper.c| 114 +++
target/arm/translate-sve.c | 133 +
target/arm/sve.decode | 27
4 files
Here's the second installment of SVE instructions.
There are about 25 patches waiting for a third installment;
this makes a nice break before beginning with the memory ops.
Since v3, r-b tags, comment fixes, and other review feedback.
r~
Richard Henderson (18):
target/arm: Extend
Rearrange the arithmetic so that we are agnostic about the total size
of the vector and the size of the element. This will allow us to index
up to the 32nd byte and with 16-byte elements.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.h | 26
Hello Team,
I am looking in your repository for any testsuite to test the semantics
for x86-64 instruction. But unfortunately did not get any success. Do
you guys mind pointing me ot the right place.
Regards,
Sandeep
On 06/05/2018 08:02 AM, Peter Maydell wrote:
>> +if (count & 63) {
>> +d->p[i] = ~(-1ull << (count & 63)) & esz_mask;
>
> Is this d->p[i] = MAKE_64BIT_MASK(0, count & 63) & esz_mask; ?
Fixed.
>> +tcg_gen_setcond_i64(cond, cmp, rn, rm);
>> +tcg_gen_extrl_i64_i32(cpu_NF,
On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> Signed-off-by: BALATON Zoltan
> ---
> default-configs/ppc-softmmu.mak| 1 +
> default-configs/ppcemb-softmmu.mak | 1 +
> hw/i2c/ppc4xx_i2c.c| 14 +-
> 3 files changed, 15 insertions(+), 1
On Fri, Jun 08, 2018 at 11:20:50AM +0200, BALATON Zoltan wrote:
> On Fri, 8 Jun 2018, David Gibson wrote:
> > On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> > > Signed-off-by: BALATON Zoltan
> >
> > It's not clear to me why this is preferable to having the registers
> >
On 06/04/2018 06:46 AM, Peter Maydell wrote:
>> +do_clast_scalar(s, a->esz, a->pg, a->rn, before, cpu_reg(s, a->rd));
>
> Why do we use cpu_reg() again here rather than just using 'reg' ?
Fixed.
r~
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 3:49 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei) ; longpeng
> ; pa...@linux.ibm.com; borntrae...@de.ibm.com;
> fran...@linux.ibm.com; al...@linux.ibm.com
>
On Tue, Jun 12, 2018 at 07:04:15PM +0200, Greg Kurz wrote:
> Bits set in the PCR disable features of the processor. TCG currently
> doesn't implement that, ie, we always act like if PCR is all zeros.
>
> But it is still possible for the PCR to have a non-null value. This may
> confuse the guest.
On Tue, Jun 12, 2018 at 08:13:49AM +0200, Cédric Le Goater wrote:
> On 06/12/2018 07:58 AM, David Gibson wrote:
> > On Wed, Jun 06, 2018 at 09:04:10AM +0200, Cédric Le Goater wrote:
> >> On 06/06/2018 08:39 AM, David Gibson wrote:
> >>> On Wed, May 30, 2018 at 12:07:54PM +0200, Cédric Le Goater
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:08 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com; fran...@linux.ibm.com;
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:07 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com; fran...@linux.ibm.com;
On 6/12/2018 4:54 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy guest without
support for the feature might
On 6/12/2018 4:34 AM, Michael S. Tsirkin wrote:
On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote:
On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
On Mon, May 07, 2018
In the context of a monitor based disk resize, provide notification
of the new size to the front end xen block driver via a xenstore update.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 7 +++
blockdev.c | 8
hw/block/xen_disk.c|
Provide monitor naming of xen disks, including associating an
attached dev_id for a BlockBackend which has legacy_dev set.
Currently, only xen disks have legacy_dev set to true.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 5 -
hw/block/xen_disk.c | 15 +++
Resizing a disk on the fly is useful, including for Xen guests.
Xen has this capability, except in the case of qdisks (Xen QEMU disks).
This patch series intends to provide this capability. With these
patches, the xl command "qemu-monitor-command" can be used in
conjunction with the "info block"
On Tue, Jun 12, 2018 at 12:11:35PM +0200, Cédric Le Goater wrote:
> On CentOS 7.5, gcc-4.8.5-28.el7_5.1.ppc64le fails to build QEMU due to :
>
> hw/intc/xics_kvm.c: In function ‘ics_set_kvm_state’:
> hw/intc/xics_kvm.c:281:13: error: ‘ret’ may be used uninitialized in this
> function
On Tue, Jun 12, 2018 at 05:43:55PM +0100, Mark Cave-Ayland wrote:
> This patchset is based upon Ben H's experimental branch which adds PMU
> support to the QEMU mac99 machine. Currently mac99 uses the via-cuda
> device which works in a lot of cases, but many OSs such as MacOS 10.5
> only support
On Tue, Jun 12, 2018 at 08:46:03PM +0200, Greg Kurz wrote:
> On Tue, 12 Jun 2018 16:55:08 +0100
> Peter Maydell wrote:
>
> > On 12 June 2018 at 16:52, Greg Kurz wrote:
> > > On Tue, 12 Jun 2018 15:34:22 +0100
> > > Peter Maydell wrote:
> > >
> > >> On 12 June 2018 at 07:44, David Gibson
>
On Tue, Jun 12, 2018 at 06:27:54PM +0200, Greg Kurz wrote:
> Commit 9d6f106552fa moved the last line in this block to somewhere else,
> but it forgot to remove the now useless #if/#endif.
>
> Signed-off-by: Greg Kurz
Applied to ppc-for-3.0, thanks.
> ---
> target/ppc/cpu.h |2 --
> 1 file
On Tue, Jun 12, 2018 at 07:01:26PM +0200, Greg Kurz wrote:
> If the negotiated compat mode can't be set, but raw mode is supported,
> we decide to ignore the error. An so, we should free it to prevent a
> memory leak.
>
> Signed-off-by: Greg Kurz
Applied to ppc-for-3.0, thanks.
> ---
>
Quoting Cornelia Huck (2018-05-15 03:09:49)
> On Tue, 15 May 2018 09:18:52 +0200
> Thomas Huth wrote:
>
> > On 15.05.2018 08:31, Olaf Hering wrote:
> > > Currently the minimal supported version of glib is 2.22.
> > > Since testing is done with a glib that claims to be 2.22, but in fact
> > > has
Also add a few more details regarding normal master->stable patch
flow.
Cc: Cornelia Huck
Signed-off-by: Michael Roth
---
docs/devel/stable-process.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/devel/stable-process.rst b/docs/devel/stable-process.rst
index
On 06/12/2018 06:11 PM, John Snow wrote:
>
>
> On 06/12/2018 01:26 PM, Vladimir Sementsov-Ogievskiy wrote:
>> First: this variable was introduced to handle reopens. We need it on
>> following qcow2_do_open, to don't try loading bitmaps again. So, we are
>> fixing qcow2_invalidate_cache().
>>
On 06/12/2018 01:26 PM, Vladimir Sementsov-Ogievskiy wrote:
> First: this variable was introduced to handle reopens. We need it on
> following qcow2_do_open, to don't try loading bitmaps again. So, we are
> fixing qcow2_invalidate_cache().
>
> However, if we fix only qcow2_invalidate_cache,
On 06/11/2018 02:56 AM, Peter Maydell wrote:
> The API for cpu_transaction_failed() says that it takes the physical
> address for the failed transaction. However we were actually passing
> it the offset within the target MemoryRegion. We don't currently
> have any target CPU implementations of
On 06/11/2018 02:56 AM, Peter Maydell wrote:
> The 'addr' field in the CPUIOTLBEntry struct has a rather non-obvious
> use; add a comment documenting it (reverse-engineered from what
> the code that sets it is doing).
>
> Signed-off-by: Peter Maydell
> ---
> include/exec/cpu-defs.h | 9
my bad, the line should be :
source ./common.sh
not "source ./common"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1776478
Title:
Getting qemu: uncaught target signal 6 when running lv2 plugin
Hey,
Not sure how to boil it down (yet). But this would reproduce it for you:
cd /tmp
wget
https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-04-19/2018-04-18-raspbian-stretch-lite.zip
unzip 2018-04-18-raspbian-stretch-lite.zip
wget
On 06/12/2018 11:04 AM, Eric Blake wrote:
> On 06/12/2018 03:51 PM, Richard Henderson wrote:
>> On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote:
>>> xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename
>>> \"%s\","
>>> - " size %" PRId64 " (%" PRId64 "
On 06/11/2018 07:52 AM, Peter Maydell wrote:
> On 11 June 2018 at 18:10, Peter Maydell wrote:
>> There's a common pattern in QEMU where a function needs to perform
>> a data load or store of an N byte integer in a particular endianness.
>> At the moment this is handled by doing a switch() on the
On 06/12/2018 03:51 PM, Richard Henderson wrote:
On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote:
xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename \"%s\","
- " size %" PRId64 " (%" PRId64 " MB)\n",
+ " size %" PRId64 " (%llu MB)\n",
On 06/11/2018 07:10 AM, Peter Maydell wrote:
> Now we have stn_p() and ldn_p() we can use them in various
> functions in exec.c that used to have their own switch-on-size code.
>
> Signed-off-by: Peter Maydell
> ---
Reviewed-by: Richard Henderson
r~
On 06/11/2018 07:10 AM, Peter Maydell wrote:
> In subpage_read() we perform a load of the data into a local buffer
> which we then access using ldub_p(), lduw_p(), ldl_p() or ldq_p()
> depending on its size, storing the result into the uint64_t *data.
> Since ldl_p() returns an 'int', this means
On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote:
> xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename
> \"%s\","
> - " size %" PRId64 " (%" PRId64 " MB)\n",
> + " size %" PRId64 " (%llu MB)\n",
>blkdev->type,
ARMv6-M supports 6 Thumb2 instructions. This patch checks for these
instructions and allows their execution.
Like Thumb2 cores, ARMv6-M always interprets BL instruction as 32-bit.
This patch is required for future Cortex-M0 support.
Signed-off-by: Julia Suvorova
---
target/arm/translate.c | 35
1 - 100 of 394 matches
Mail list logo
