On Sat, 27 Apr 2019 15:56:42 +0200
Philippe Mathieu-Daudé wrote:
> When writing a new board, adding device which uses other devices
> (container) or simply refactoring, one can discover the hard way
> his machine misses some devices. In the case of containers, the
> error is not obvious:
>
> $
Hi,
> > What questions for example?
>
> This opens up different kind of possible replies, and error handling.
>
> With current proposal and needs, the reply (or absence of reply) is
> entirely driven by the request.
>
> With your proposal, should all request have a reply?
Yes.
> which makes
From: Longpeng
we found the following core in our environment:
0 0x7fc6b06c2237 in raise ()
1 0x7fc6b06c3928 in abort ()
2 0x7fc6b06bb056 in __assert_fail_base ()
3 0x7fc6b06bb102 in __assert_fail ()
4 0x00702e36 in xhci_kick_ep (...)
6 0x0047767f in access_w
On Wed, Apr 24, 2019 at 09:19:17AM +0200, Kevin Wolf wrote:
Am 24.04.2019 um 08:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
23.04.2019 18:08, Kevin Wolf wrote:
> Am 23.04.2019 um 16:26 hat Martin Kletzander geschrieben:
>> On Tue, Apr 23, 2019 at 02:12:18PM +0200, Kevin Wolf wrote:
>>> Am 2
On 26.04.19 14:55, Cornelia Huck wrote:
> On Fri, 26 Apr 2019 14:05:30 +0200
> David Hildenbrand wrote:
>
>> On 26.04.19 14:01, Christian Borntraeger wrote:
>>>
>>>
>>> On 26.04.19 13:52, David Hildenbrand wrote:
On 26.04.19 13:36, Christian Borntraeger wrote:
>
>
> On 26.
We tested our situation with Qemu 4.0 and we are unable to reproduce the issue.
So it looks like the issue has been fixed in a more recent version.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/182433
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824331
Title:
Qemu Crashes
Status in QEMU:
Fix Released
Bug description:
A high vo
Hi Philippe,
Le 4/27/19 à 6:29 PM, Philippe Mathieu-Daudé a écrit :
Currently the Leon3 machine doesn't allow to load legacy u-boot images:
$ qemu-system-sparc -M leon3_generic -d in_asm \
-kernel HelenOS-0.6.0-sparc32-leon3.bin
qemu-system-sparc: could not load kernel 'HelenOS-0.6
29.04.2019 3:37, Max Reitz wrote:
> On 02.04.19 17:37, Vladimir Sementsov-Ogievskiy wrote:
>> v5: rebase on master, some conflicts resolved due to data-file feature
>>
>> 01: new patch, just move test from cover letter to a file. I really hope
>> that it
>> will not hang the whole series, so,
Am 15.04.2019 um 17:54 hat Kevin Wolf geschrieben:
> Kevin Wolf (4):
> qcow2: Avoid COW during metadata preallocation
> qcow2: Fix preallocation bdrv_pwrite to wrong file
> qcow2: Add errp to preallocate_co()
> qcow2: Fix full preallocation with external data file
Applied the remaining pat
8561 and 8562 will be gen15 machines. There is no name yet, lets us use
gen15a and gen15tb as base name. Later on we can provide aliases with
the proper name.
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_models.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff -
Provide the "Miscellaneous-Instruction-Extensions Facility 3" via
stfle.61.
Signed-off-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
---
target/s390x/cpu_features.c | 1 +
target/s390x/cpu_features_def.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/target/s390x/cpu_featu
Provide the MSA9 facility (stfle.155).
This also contains pckmo functions for key wrapping. Keep them in a
separate group to disable those as a block if necessary.
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_features.c | 32 +
target/s390x/cpu_features.h
add several new features (msa9, sort, deflate, additional vector
instructions, new general purpose instructions) to generation 15.
Also disable csske and bpb from the default and base models >=15.
This will allow to migrate gen15 machines to future machines that
do not have these features.
Signed
29.04.2019 10:27, Martin Kletzander wrote:
> On Wed, Apr 24, 2019 at 09:19:17AM +0200, Kevin Wolf wrote:
>> Am 24.04.2019 um 08:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> 23.04.2019 18:08, Kevin Wolf wrote:
>>> > Am 23.04.2019 um 16:26 hat Martin Kletzander geschrieben:
>>> >> On Tue, Apr
add the enhanced sort facility.
Signed-off-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
---
target/s390x/cpu_features.c | 10 ++
target/s390x/cpu_features.h | 1 +
target/s390x/cpu_features_def.h | 8
target/s390x/gen-features.c | 14 ++
ta
Add vector enhancements to the cpu model.
Signed-off-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
---
target/s390x/cpu_features.c | 2 ++
target/s390x/cpu_features_def.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_feature
Hi all!
Here some refactoring patches, as a first step for backup-top filter
introduction.
v7:
01,03,04: add Max's r-b
05: fix s/return NULL/goto error/ [Max]
v6:
01: - use end_cluster instead of last_cluster and fix bug in
calculation [Max]
02: only rebased on 01, keep r-b
03, 04: new
05:
add the deflate conversion facility.
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_features.c | 9 +
target/s390x/cpu_features.h | 1 +
target/s390x/cpu_features_def.h | 7 +++
target/s390x/gen-features.c | 12
target/s390x/kvm.c |
On 29.04.19 10:53, Cornelia Huck wrote:
> On Mon, 29 Apr 2019 09:51:39 +0200
> Christian Borntraeger wrote:
>
>> On 26.04.19 14:55, Cornelia Huck wrote:
>>> On Fri, 26 Apr 2019 14:05:30 +0200
>>> David Hildenbrand wrote:
>>>
On 26.04.19 14:01, Christian Borntraeger wrote:
>
Am 13.04.2019 um 17:20 hat Max Reitz geschrieben:
> https://bugzilla.redhat.com/show_bug.cgi?id=1698863 reports that while
> "qemu-img create -f raw" supports the "preallocation" option, it is not
> listed under "-o help".
>
> It turns out it is, but only if you specify a target filename. Users
>
to be replaced by a proper one
Signed-off-by: Christian Borntraeger
---
linux-headers/asm-s390/kvm.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0265482f8f..03ab5968c7 100644
--- a/linux-headers/asm-s39
Split allocation checking to separate function and reduce nesting.
Consider bdrv_is_allocated() fail as allocated area, as copying more
than needed is not wrong (and we do it anyway) and seems better than
fail the whole job. And, most probably we will fail on the next read,
if there are real proble
On Mon, Apr 29, 2019 at 08:58:37AM +, Vladimir Sementsov-Ogievskiy wrote:
29.04.2019 10:27, Martin Kletzander wrote:
On Wed, Apr 24, 2019 at 09:19:17AM +0200, Kevin Wolf wrote:
Am 24.04.2019 um 08:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
23.04.2019 18:08, Kevin Wolf wrote:
> Am 23.
csske will be removed in a future machine. Ignore it for expanding the
cpu model. Otherwise qemu falls back to z9.
Signed-off-by: Christian Borntraeger
Cc: qemu-sta...@nongnu.org
Reviewed-by: David Hildenbrand
---
target/s390x/cpu_models.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t
Do full, top and incremental mode copying all in one place. This
unifies the code path and helps further improvements.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
block/backup.c | 43 ++-
1 file changed, 10 insertions(+), 33 del
27.04.2019 1:15, John Snow wrote:
> If we add references that don't resolve (or accidentally remove them),
> it will be helpful to have an error message alerting us to that.
the wording still a bit in conflict with the fact that -n is originally a
warning, not error,
but I don't really care:
Rev
Adding gen15.
v2->v3: - merge deprecation patch into gen 15 patch
- fix comments
- use gen15a and gen15b instead of cpuid
v1->v2: - rework csske deprecation
- white space fixes
- also require msa4 for msa9
Christian Borntraeger (9):
linux header sync
s390x/cpu
On Mon, 29 Apr 2019 09:51:39 +0200
Christian Borntraeger wrote:
> On 26.04.19 14:55, Cornelia Huck wrote:
> > On Fri, 26 Apr 2019 14:05:30 +0200
> > David Hildenbrand wrote:
> >
> >> On 26.04.19 14:01, Christian Borntraeger wrote:
> >>>
> >>>
> >>> On 26.04.19 13:52, David Hildenbrand wrote
Simplify backup_incremental_init_copy_bitmap using the function
bdrv_dirty_bitmap_next_dirty_area.
Note: move to job->len instead of bitmap size: it should not matter but
less code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
block/backup.c | 40 -
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9] s390x
Split out cluster_size calculation. Move copy-bitmap creation above
block-job creation, as we are going to share it with upcoming
backup-top filter, which also should be created before actual block job
creation.
Also, while being here, drop unnecessary "goto error" from
bdrv_getlength error path.
We are going to share this bitmap between backup and backup-top filter
driver, so let's share something more meaningful. It also simplifies
some calculations.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
block/backup.c | 48 +++--
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9] s390x
27.04.2019 1:15, John Snow wrote:
> This just about rewrites the entirety of the bitmaps.rst document to
> make it consistent with the 4.0 release. I have added new features seen
> in the 4.0 release, as well as tried to clarify some points that keep
> coming up when discussing this feature both in
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9] s390x
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9] s390x
On Mon, 29 Apr 2019 at 10:36, Damien Hedde wrote:
>
> Hi All,
>
> Any comment about this ?
Sorry we haven't got to this yet. This is on my to-review list,
but so are 23 other series, and I've been on holiday for the
past week or so. I will try to get to it this week.
thanks
-- PMM
Hi All,
Any comment about this ?
Thanks,
Damien
On 3/25/19 12:01 PM, Damien Hedde wrote:
> Hi all,
>
> This series is a proposal to implement the multi-phase reset we've discussed
> here (https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg00310.html) and
> more recently there
> (https://l
Am 23.04.2019 um 10:38 hat Kevin Wolf geschrieben:
> Am 23.04.2019 um 10:26 hat Stefano Garzarella geschrieben:
> > On Tue, Apr 23, 2019 at 09:56:19AM +0200, Kevin Wolf wrote:
> > > Am 19.04.2019 um 14:23 hat Stefano Garzarella geschrieben:
> > > > Hi Kevin,
> > > >
> > > > On Wed, Apr 17, 2019 at
On 29.04.19 11:02, Christian Borntraeger wrote:
> 8561 and 8562 will be gen15 machines. There is no name yet, lets us use
> gen15a and gen15tb as base name. Later on we can provide aliases with
nit: gen15b
> the proper name.
>
> Signed-off-by: Christian Borntraeger
> ---
> target/s390x/cpu_mod
On 29.04.19 11:02, Christian Borntraeger wrote:
> add several new features (msa9, sort, deflate, additional vector
> instructions, new general purpose instructions) to generation 15.
>
> Also disable csske and bpb from the default and base models >=15.
> This will allow to migrate gen15 machines t
On 29.04.19 11:02, Christian Borntraeger wrote:
> add the deflate conversion facility.
>
> Signed-off-by: Christian Borntraeger
> ---
> target/s390x/cpu_features.c | 9 +
> target/s390x/cpu_features.h | 1 +
> target/s390x/cpu_features_def.h | 7 +++
> target/s390x/gen-fea
On Mon, Apr 29, 2019 at 11:58:55AM +0200, Kevin Wolf wrote:
>
> Hm, this is an RFC patch, which suggests that it wasn't originally meant
> to be merged as it is. Are you going to send a new version, or did it
> turn out to be exactly what we want and the "RFC" tag was a mistake?
I put the "RFC" t
> I dont think that I know the name in time before the next release.
> So lets go with gen15a/gen15b or 8561/8562?
>
We can still fixup if the names happen to be known earlier.
--
Thanks,
David / dhildenb
Am 11.04.2019 um 12:50 hat Stefano Garzarella geschrieben:
> RBD APIs don't allow us to write more than the size set with rbd_create()
> or rbd_resize().
> In order to support growing images (eg. qcow2), we resize the image
> before RW operations that exceed the current size.
>
> Buglink: https://
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9] s390x
Am 26.04.2019 um 14:24 hat Anton Kuchin geschrieben:
> I can't figure out ownership of aio context during bdrv_close().
>
> As far as I understand bdrv_unref() shold be called with acquired aio
> context to prevent concurrent operations (at least most usages in blockdev.c
> explicitly acquire and
Hi
On Mon, Apr 29, 2019 at 9:12 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > What questions for example?
> >
> > This opens up different kind of possible replies, and error handling.
> >
> > With current proposal and needs, the reply (or absence of reply) is
> > entirely driven by the request.
> >
>
make_completely_empty() is an optimisated path for bdrv_make_empty()
where completely new metadata is created inside the image file instead
of going through all clusters and discarding them. For an external data
file, however, we actually need to do discard operations on the data
file; just overwri
Hi Mike,
On 4/29/19 9:39 AM, Longpeng(Mike) wrote:
> From: Longpeng
>
> we found the following core in our environment:
> 0 0x7fc6b06c2237 in raise ()
> 1 0x7fc6b06c3928 in abort ()
> 2 0x7fc6b06bb056 in __assert_fail_base ()
> 3 0x7fc6b06bb102 in __assert_fail ()
> 4 0x
Am 29.04.2019 um 12:57 hat Kevin Wolf geschrieben:
> make_completely_empty() is an optimisated path for bdrv_make_empty()
> where completely new metadata is created inside the image file instead
> of going through all clusters and discarding them. For an external data
> file, however, we actually n
CC'ing Thomas who is a Kconfig expert.
On 3/17/19 12:44 AM, Philippe Mathieu-Daudé wrote:
> Explicit the CY82C693UB southbridge used by the 264DP.
>
> Philippe Mathieu-Daudé (2):
> hw/isa/southbridge: Add the Cypress 82C693UB chipset
> hw/alpha/Kconfig: The 264DP machine use a CY82C693UB sout
Hi Philippe,
On 2019/4/29 19:16, Philippe Mathieu-Daudé wrote:
> Hi Mike,
>
> On 4/29/19 9:39 AM, Longpeng(Mike) wrote:
>> From: Longpeng
>>
>> we found the following core in our environment:
>> 0 0x7fc6b06c2237 in raise ()
>> 1 0x7fc6b06c3928 in abort ()
>> 2 0x7fc6b06bb056 in _
On Thu, 11 Apr 2019 at 17:10, Cédric Le Goater wrote:
>
> Hello,
>
> Here is a series adding a couple of cleanups to the Aspeed SoCs to
> prepare ground for extensions and new SoCs.
>
> Thanks,
>
> C.
>
> Cédric Le Goater (3):
> aspeed: add a per SoC mapping for the interrupt space
> aspeed: a
On 4/29/19 1:42 PM, Longpeng (Mike) wrote:
> Hi Philippe,
>
> On 2019/4/29 19:16, Philippe Mathieu-Daudé wrote:
>
>> Hi Mike,
>>
>> On 4/29/19 9:39 AM, Longpeng(Mike) wrote:
>>> From: Longpeng
>>>
>>> we found the following core in our environment:
>>> 0 0x7fc6b06c2237 in raise ()
>>> 1 0x
On 24.04.19 12:37, Thomas Huth wrote:
> People often forget to run the iotests before submitting patches or
> pull requests - this is likely due to the fact that we do not run the
> tests during our mandatory "make check" tests yet.
> This patch series now introduces a new "ci" iotests group that s
On Mon, 29 Apr 2019 at 13:07, Peter Maydell wrote:
>
> On Thu, 11 Apr 2019 at 17:10, Cédric Le Goater wrote:
> >
> > Hello,
> >
> > Here is a series adding a couple of cleanups to the Aspeed SoCs to
> > prepare ground for extensions and new SoCs.
> >
> > Thanks,
> >
> > C.
> >
> > Cédric Le Goate
* Zhang Chen (chen.zh...@intel.com) wrote:
> From: Zhang Chen
>
> We missed the iothread related args in this file.
> This patch is used to fix this issue.
>
> Signed-off-by: Zhang Chen
OK.
Reviewed-by: Dr. David Alan Gilbert
> ---
> qemu-options.hx | 9 ++---
> 1 file changed, 6 inse
On Sat, 27 Apr 2019 at 14:30, Philippe Mathieu-Daudé wrote:
>
> This device is used by both ARM (BCM2836, for raspi2) and AArch64
> (BCM2837, for raspi3) targets, and is not CPU-specific.
> Move it to common object, so we build it once for all targets.
>
> Signed-off-by: Philippe Mathieu-Daudé
>
On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote:
> On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi wrote:
> > On Thu, Apr 25, 2019 at 08:07:06PM +0200, Philippe Mathieu-Daudé wrote:
> > Old boards probably want to continue using -kernel. New boards like
> > microbit may use just -devi
* Zhang Chen (chen.zh...@intel.com) wrote:
> From: Zhang Chen
>
> The colo_do_failover no need the input parameter.
>
> Signed-off-by: Zhang Chen
Reviewed-by: Dr. David Alan Gilbert
> ---
> include/migration/colo.h | 2 +-
> migration/colo-failover.c | 2 +-
> migration/colo.c | 2
* Zhang Chen (chen.zh...@intel.com) wrote:
> From: Zhang Chen
>
> Signed-off-by: Zhang Chen
Reviewed-by: Dr. David Alan Gilbert
> ---
> include/migration/colo.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/migration/colo.h b/include/migration/colo.h
> index ddebe0ad27..
Hi Alistair,
Le 4/29/19 à 7:33 AM, Alistair Francis a écrit :
Signed-off-by: Alistair Francis
---
MAINTAINERS | 8 +
default-configs/arm-softmmu.mak | 1 +
hw/arm/Kconfig | 3 +
hw/arm/Makefile.objs| 1 +
hw/arm/stm32f405_soc.c
On 4/29/19 7:33 AM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> MAINTAINERS | 8 +
> default-configs/arm-softmmu.mak | 1 +
> hw/arm/Kconfig | 3 +
> hw/arm/Makefile.objs| 1 +
> hw/arm/stm32f405_soc.c | 292 +
On Sat, Apr 27, 2019 at 08:43:26AM -0400, Jason Dillaman wrote:
> On Sat, Apr 27, 2019 at 7:37 AM Stefano Garzarella
> wrote:
> >
> > This patch adds the support of preallocation (off/full) for the RBD
> > block driver.
> > If available, we use rbd_writesame() to quickly fill the image when
> > f
On Wed, 3 Apr 2019 at 20:53, Sandra Loosemore wrote:
>
> This patch adds support for a generic MMU-less Nios II board that can
> be used e.g. for bare-metal compiler testing with the linker script
> and startup code provided by libgloss. Nios II booting is also
> tweaked so that bare-metal binari
On Fri, 15 Mar 2019 at 03:49, Richard Henderson
wrote:
>
> We will shortly need this in the user-only binaries, so drop the split
> into system and tools binaries. This also means that crypto-aes-obj-y
> can be merged back into crypto-obj-y.
>
> Cc: Daniel P. Berrangé
> Signed-off-by: Richard He
On Mon, 29 Apr 2019 at 13:28, Stefan Hajnoczi wrote:
>
> On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote:
> I was going to add a function to check kernel_filename and the presence
> of -device loader. Then each machine type init function would call the
> function with flags indicati
On Mon, Apr 29, 2019 at 8:47 AM Stefano Garzarella wrote:
>
> On Sat, Apr 27, 2019 at 08:43:26AM -0400, Jason Dillaman wrote:
> > On Sat, Apr 27, 2019 at 7:37 AM Stefano Garzarella
> > wrote:
> > >
> > > This patch adds the support of preallocation (off/full) for the RBD
> > > block driver.
> >
Newer versions of zipl have the ability to write signature entries to the boot
script for secure boot. We don't yet support secure boot, but we need to skip
over signature entries while reading the boot script in order to maintain our
ability to boot guest operating systems that have a secure bootl
On 29/04/2019 07.09, Li Qiang wrote:
>
>
> Li Qiang mailto:liq...@gmail.com>> 于2019年4月25日周
> 四 下午10:29写道：
>
>
>
> Thomas Huth mailto:th...@redhat.com>> 于2019年4月
> 25日周四 下午5:57写道：
>
> On 24/04/2019 16.06, Li Qiang wrote:
> > In the disscuss of adding reboot timeout test
On 13/12/2018 04.24, David Gibson wrote:
> On Thu, Aug 30, 2018 at 04:33:48PM +0200, Marc-André Lureau wrote:
>> Remove -sandbox option if the host is not capable of TSYNC, since the
>> sandbox will fail at setup time otherwise. This will help libvirt, for
>> ex, to figure out if -sandbox will work
On Thu, 28 Mar 2019 at 23:40, Richard Henderson
wrote:
>
> For all targets, into this new file move TARGET_LONG_BITS,
> TARGET_PAGE_BITS, TARGET_PHYS_ADDR_SPACE_BITS,
> TARGET_VIRT_ADDR_SPACE_BITS, and NB_MMU_MODES.
>
> Include this new file from exec/cpu-defs.h.
>
> This now removes the somewhat
On Mon, 29 Apr 2019 09:09:41 -0400
"Jason J. Herne" wrote:
> Newer versions of zipl have the ability to write signature entries to the boot
> script for secure boot. We don't yet support secure boot, but we need to skip
> over signature entries while reading the boot script in order to maintain o
On Fri, Apr 26, 2019 at 10:14:16AM +0200, Paolo Bonzini wrote:
> On 23/04/19 14:04, Stefan Hajnoczi wrote:
> >> In addition, does Virtio-scsi support Batch I/O Submission feature
> >> which may be able to increase the IOPS via reducing the number of
> >> system calls?
> >
> > I don't see obvious ba
On Thu, 28 Mar 2019 at 23:52, Richard Henderson
wrote:
>
> Move all softmmu tlb data into this structure. Arrange the
> members so that we are able to place mask+table together and
> at a smaller absolute offset from ENV.
>
> Acked-by: Alistair Francis
> Signed-off-by: Richard Henderson
> ---
On Thu, 28 Mar 2019 at 23:35, Richard Henderson
wrote:
>
> For all targets, do this just before including exec/cpu-all.h.
>
> Acked-by: Alistair Francis
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 28 Mar 2019 at 23:47, Richard Henderson
wrote:
>
> For all targets, do this just before including exec/cpu-all.h.
>
> Acked-by: Alistair Francis
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Fri, Apr 26, 2019 at 06:15:28PM -0400, John Snow wrote:
> This just about rewrites the entirety of the bitmaps.rst document to
> make it consistent with the 4.0 release. I have added new features seen
> in the 4.0 release, as well as tried to clarify some points that keep
> coming up when discus
On 29.04.19 15:40, Cornelia Huck wrote:
> On Mon, 29 Apr 2019 09:09:41 -0400
> "Jason J. Herne" wrote:
>
>> Newer versions of zipl have the ability to write signature entries to the
>> boot
>> script for secure boot. We don't yet support secure boot, but we need to skip
>> over signature entr
Thomas Huth 于2019年4月29日周一 下午9:18写道：
> On 29/04/2019 07.09, Li Qiang wrote:
> >
> >
> > Li Qiang mailto:liq...@gmail.com>> 于2019年4月25日周
> > 四 下午10:29写道：
> >
> >
> >
> > Thomas Huth mailto:th...@redhat.com>> 于2019年4月
> > 25日周四 下午5:57写道：
> >
> > On 24/04/2019 16.06, Li Qiang wrote:
>
On Thu, 28 Mar 2019 at 23:41, Richard Henderson
wrote:
>
> Now that we have both ArchCPU and CPUArchState, we can define
> this generically instead of via macro in each target's cpu.h.
>
> Acked-by: Alistair Francis
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
--
On Thu, 28 Mar 2019 at 23:29, Richard Henderson
wrote:
>
> This will foo_env_get_cpu with a generic definition.
This sentence no verb.
> No changes to the target specific code so far.
>
> Signed-off-by: Richard Henderson
> ---
Otherwise
Reviewed-by: Peter Maydell
thanks
-- PMM
$ ./x86_64-softmmu/qemu-system-x86_64 -sandbox off
qemu-system-x86_64: -sandbox off: There is no option group 'sandbox'
Segmentation fault
Commit 5780760f5e ("seccomp: check TSYNC host capability") wrapped one
use of the sandbox option group to produce a sensible error, it didn't
do the same for a
Hi
On Mon, Apr 29, 2019 at 3:22 PM Thomas Huth wrote:
>
> On 13/12/2018 04.24, David Gibson wrote:
> > On Thu, Aug 30, 2018 at 04:33:48PM +0200, Marc-André Lureau wrote:
> >> Remove -sandbox option if the host is not capable of TSYNC, since the
> >> sandbox will fail at setup time otherwise. This
You can reproduce this by passing an invalid filter-node-name (like
"1234") to block-commit. In this case the base image is put in
read-write mode but is never reset back to read-only.
Signed-off-by: Alberto Garcia
Reviewed-by: Max Reitz
---
block/commit.c | 3 +++
1 file changed, 3 insertions(
Hi,
Here's v3 of this series, the only changes are the corrections in the
iotest suggested by Max.
Regards,
Berto
v3:
- Patch 2: Use $() instead of backquotes, remove 'here' variable and
don't use 'sleep' when waiting for block-commit to finish [Max]
v2: https://lists.gnu.org/archive/html/qe
This tests the fix from the previous patch.
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/249 | 115 +
tests/qemu-iotests/249.out | 35 ++
tests/qemu-iotests/group | 1 +
3 files changed, 151 insertions(+)
create mode 10075
On Fri, 26 Apr 2019 at 09:17, Stefan Hajnoczi wrote:
>
> A user-friendly error message is needed here. The check for -kernel was
> too specific and is not desirable for microbit where we use -device
> loader.
>
> Old boards probably want to continue using -kernel. New boards like
> microbit may
On Thu, 28 Mar 2019 at 23:23, Richard Henderson
wrote:
>
> With exactly one exception, most uses of alpha_env_get_cpu
> were failures to use the more proper, ENV_GET_CPU macro,
> now replaced by env_cpu.
>
> Signed-off-by: Richard Henderson
> ---
> target/alpha/cpu.h | 5 -
> linux-
On Mon, Apr 29, 2019 at 12:25:10PM +0200, Kevin Wolf wrote:
> Am 11.04.2019 um 12:50 hat Stefano Garzarella geschrieben:
> > RBD APIs don't allow us to write more than the size set with rbd_create()
> > or rbd_resize().
> > In order to support growing images (eg. qcow2), we resize the image
> > bef
On Thu, 28 Mar 2019 at 23:51, Richard Henderson
wrote:
>
> Combined uses of CPU(arm_env_get_cpu()) were failures to use
> the more proper, ENV_GET_CPU macro, now replaced by env_cpu.
>
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
(though I imagine that this will need upd
On 4/29/19 3:47 PM, Marc-André Lureau wrote:
> $ ./x86_64-softmmu/qemu-system-x86_64 -sandbox off
> qemu-system-x86_64: -sandbox off: There is no option group 'sandbox'
> Segmentation fault
>
> Commit 5780760f5e ("seccomp: check TSYNC host capability") wrapped one
> use of the sandbox option group
On Mon, Apr 29, 2019 at 09:00:26AM -0400, Jason Dillaman wrote:
> On Mon, Apr 29, 2019 at 8:47 AM Stefano Garzarella
> wrote:
> >
> > On Sat, Apr 27, 2019 at 08:43:26AM -0400, Jason Dillaman wrote:
> > > On Sat, Apr 27, 2019 at 7:37 AM Stefano Garzarella
> > > wrote:
> > > >
> > > > This patch
On Thu, 28 Mar 2019 at 23:32, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/cris/cpu.h | 5 -
> linux-user/cris/cpu_loop.c | 2 +-
> target/cris/mmu.c | 3 +--
> target/cris/op_helper.c| 10 +++---
> target/cris/translate.c| 2
On Thu, 28 Mar 2019 at 23:26, Richard Henderson
wrote:
>
> Combined uses of CPU(hppa_env_get_cpu()) were failures to use
> the more proper, ENV_GET_CPU macro, now replaced by env_cpu.
>
> Signed-off-by: Richard Henderson
> ---
> target/hppa/cpu.h | 5 -
> linux-user/hppa/cpu_loop.c
On 3/29/19 12:03 AM, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
> ---
> target/mips/cpu.h| 5 -
> hw/intc/mips_gic.c | 2 +-
> hw/mips/mips_int.c | 2 +-
> linux-user/mips/cpu_loop.c |
On Thu, 28 Mar 2019 at 23:48, Richard Henderson
wrote:
>
> Combined uses of CPU(x86_env_get_cpu()) were failures to use
> the more proper, ENV_GET_CPU macro, now replaced by env_cpu.
>
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 28 Mar 2019 at 23:49, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/lm32/cpu.h | 5 -
> target/lm32/helper.c| 19 ++-
> target/lm32/op_helper.c | 6 +++---
> target/lm32/translate.c | 2 +-
> 4 files changed, 10 insertions(+
1 - 100 of 280 matches
Mail list logo
