Ladi Prosek writes:
> On Fri, Dec 8, 2017 at 6:28 PM, Markus Armbruster wrote:
>> Ladi Prosek writes:
>>
>>> On Fri, Dec 8, 2017 at 2:36 PM, Markus Armbruster wrote:
Ladi Prosek writes:
> The effects of ivshmem_enable_irqfd() was not undone on device reset.
>
> This mani
On 12/08/2017 08:01 AM, David Hildenbrand wrote:
> Needed for machine check handling inside Linux (when restoring registers).
>
> Except for SIGP and machine checks, we don't make use of the register
> yet. Sufficient for now.
>
> Reviewed-by: Thomas Huth
> Signed-off-by: David Hildenbrand
> --
On 12/08/2017 08:01 AM, David Hildenbrand wrote:
> We'll need it later on in two places. Refactor it to just indicate the
> validity bits. While at it, introduce a define for the used CR14 bit (we'll
> also need later on).
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cpu.h | 23
On 11/22/2017 09:08 PM, Max Reitz wrote:
> Tests 080, 130, 137, and 176 simply do not work with compat=0.10 for the
> reasons stated there.
>
> 177 is a bit more interesting: Originally, it was actually very much
> intended to work with compat=0.10 (it even had a special case for that).
> Howev
On 11/30/2017 08:23 AM, Max Reitz wrote:
> On 2017-11-30 04:18, Fam Zheng wrote:
>> On Thu, 11/23 03:08, Max Reitz wrote:
>>> Signed-off-by: Max Reitz
>>> ---
>>> tests/qemu-iotests/103 | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/tests/qemu-iotests/103 b/tests/qemu-iotests/
On 11/22/2017 09:08 PM, Max Reitz wrote:
> There is a bit of image-specific information which depends on the qcow2
> compat level. Filter it so that 198 works with compat=0.10 (and any
> refcount_bits value).
>
> Note that we cannot simply drop the --format-specific switch because we
> do need
On 11/22/2017 09:08 PM, Max Reitz wrote:
> In order for 191 to work with an explicit refcount_bits or compat=0.10,
> we should strip format-specific information from the output--and we can
> do so by using _filter_img_info.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/191 | 5
On 11/22/2017 09:08 PM, Max Reitz wrote:
> 184 does not need an image, so don't use one.
>
> Signed-off-by: Max Reitz
Seems sane.
Reviewed-by: John Snow
> ---
> tests/qemu-iotests/184 | 25 --
> tests/qemu-iotests/184.out | 63
> +++-
On Thu, Dec 07, 2017 at 06:14:48PM +, Peter Maydell wrote:
> We were passing a NULL error pointer to the object_property_set_bool()
> call that realizes the CPU object. This meant that we wouldn't detect
> failure, and would plough blindly on to crash later trying to use a
> NULL CPU object poi
On 11/22/2017 09:08 PM, Max Reitz wrote:
> The only thing that is missing is a _filter_img_info after the
> "$QEMU_IO -c info" invocations.
>
> Signed-off-by: Max Reitz
Reviewed-by: John Snow
On Thu, Dec 07, 2017 at 07:37:31PM +, Peter Maydell wrote:
> On 7 December 2017 at 18:14, Peter Maydell wrote:
> > This patchset adds support for '-cpu max' to Arm, along the lines
> > of the existing support we have for x86 targets:
> >
> > * under KVM, -cpu max is the same as -cpu host
> >
On 11/22/2017 09:08 PM, Max Reitz wrote:
> 067 works very well with compat=0.10 once you remove format-specific
> information from the QMP output.
>
> Signed-off-by: Max Reitz
Reviewed-by: John Snow
This is going to be a long one. Maybe go get a cup of coffee.
On 12/07/2017 04:39 AM, Vladimir Sementsov-Ogievskiy wrote:
> 07.12.2017 03:38, John Snow wrote:
>> I'm sorry, I don't think I understand.
>>
>> "customers needs a possibility to create a backup of data changed since
>> some point in ti
On Thu, Oct 12, 2017 at 17:03:31 +0100, Peter Maydell wrote:
> Refactor the Thumb decode to do the loads of the instruction words at
> the top level rather than only loading the second half of a 32-bit
> Thumb insn in the middle of the decode.
>
> This is simple apart from the awkward case of Thum
On 12/8/17 3:55 AM, Peter Maydell wrote:
>> If you give me example on how
>> to trigger this type of request with debug=1 then I can look into the code
>> and see what we can do when memory encryption is enabled. The things like
>> read-clears-bits semantics will be tricky.
> The question was rea
On Sat, 28 Oct 2017, Simon Gaiser wrote:
> The passed-through device might be an express device. In this case the
> old code allocated a too small emulated config space in
> pci_config_alloc() since pci_config_size() returned the size for a
> non-express device. This leads to an out-of-bound write
This looks not a QEMU bug to me. You may drop "-curses" first, and run
again. Once get inside, change grub file(/etc/default/grub) by uncomment
GRUB_TERMINAL=console. It should work then. If still not, then blacklist
vga16fb and add "fbcon=map:99 text" in grub command line. Remember to
run update-g
On Tue, 5 Dec 2017, Peter Maydell wrote:
> Currently get_phys_addr() and its various subfunctions return a
> hard-coded fault status register value for translation failures. This
> is awkward because FSR values these days may be either long-descriptor
> format or short-descriptor format. Worse, th
On 12/05/2017 03:33 AM, Kirill Batuzov wrote:
> On Tue, 21 Nov 2017, Richard Henderson wrote:
>
>> Signed-off-by: Richard Henderson
>
>> +void tcg_gen_mul_vec(unsigned vece, TCGv_vec r, TCGv_vec a, TCGv_vec b)
>> +{
>> +TCGTemp *rt = tcgv_vec_temp(r);
>> +TCGTemp *at = tcgv_vec_temp(a);
On 12/06/2017 02:21 AM, Kirill Batuzov wrote:
> IN:
> 0x004005e8: d2824682 movz x2, #0x1234
> 0x004005ec: 4e010c41 dup v1.16b, w2
>
> OP:
>
> 004005e8
> movi_i64 x2,$0x1234
>
> 004005ec
On 11/21/2017 09:48 PM, Alexey Kardashevskiy wrote:
> On 07/11/17 11:58, John Snow wrote:
>>
>>
>> On 10/26/2017 02:46 AM, Alexey Kardashevskiy wrote:
>>> A "powernv" machine type defines an ISA bus but it does not add any DMA
>>> controller to it so it is possible to hit assert(fdctrl->dma) by
>
On 12/08/2017 01:17 PM, Cédric Le Goater wrote:
On 12/06/2017 12:53 PM, Stefan Berger wrote:
On 12/06/2017 02:26 AM, Cédric Le Goater wrote:
Hello Stefan,
Some comments below. How do we populate the device tree ?
Patched SLOF.
Ah. Isn't that a problem ? I thought QEMU was in charge of popul
* Igor Mammedov (imamm...@redhat.com) wrote:
> vhost_verify_ring_mappings() were used to verify that
> rings are still accessible and related memory hasn't
> been moved after flatview is updated.
I think I've rolled the equivalent into my v2 I've just
posted; please have a look.
Dave
> It were d
From: "Dr. David Alan Gilbert"
Mvoe the maintenance of mem_sections into the vhost_update_mem routines,
this removes the need for the vhost_region_add/del callbacks.
Suggested-by: Igor Mammedov
(and mostly written by Igor!)
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/vhost.c | 58 +
From: "Dr. David Alan Gilbert"
Compare the temporary region data with the original, and if it's
different update the original in the device state.
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/trace-events | 2 ++
hw/virtio/vhost.c | 19 +--
2 files changed, 19 inse
From: "Dr. David Alan Gilbert"
Remove the old update mechanism, vhost_set_memory, and the functions
it uses and the memory_changed flags we no longer use.
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/vhost.c | 254 --
include/hw/virtio
From: "Dr. David Alan Gilbert"
Add the meat of update_mem_cb; this is called for each region,
to add a region to our temporary list.
Our temporary list is in order we look to see if this
region can be merged with the current head of list.
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/tr
From: "Dr. David Alan Gilbert"
vhost_update_mem will replace the existing update mechanism.
They make use of the Flatview we have now to make the update simpler.
This commit just adds the basic structure.
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/vhost.c | 51
From: "Dr. David Alan Gilbert"
vhost_verify_ring_mappings() were used to verify that
rings are still accessible and related memory hasn't
been moved after flatview is updated.
It were doing checks by mapping ring's GPA+len and
checking that HVA hasn't changed with new memory map.
To avoid maybe
From: "Dr. David Alan Gilbert"
Hi,
This is an experimental set that reworks the way the vhost
code handles changes in physical address space layout that
came from a discussion with Igor.
It's intention is to simplify a lot of the update code,
and to make it easier for the postcopy+shared code
From: "Dr. David Alan Gilbert"
Iterate through an address space calling a function for each
section. The iteration is done in order.
Signed-off-by: Dr. David Alan Gilbert
---
include/exec/memory.h | 23 +++
memory.c | 22 ++
2 files changed
From: "Dr. David Alan Gilbert"
Move the log_dirty check into vhost_section.
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/trace-events | 3 +++
hw/virtio/vhost.c | 20 +---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/hw/virtio/trace-events b/hw/v
> On Dec 8, 2017, at 1:41 PM, John Snow <1737...@bugs.launchpad.net> wrote:
>
> If you do two identical installs with qcow2 and raw, do you see any
> differences with qemu-img compare afterwards that might indicate what
> could possibly have gone wrong?
I think what you want is for me to compare
On 12/08/2017 07:10 AM, Anton Nefedov wrote:
> Started from the separate series discussion (trim statistics) , see
> http://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg01059.html
>
> There is no range check for IDE trim requests now.
> Such request will likely be rejected by the block la
On 12/08/2017 11:56 AM, Paolo Bonzini wrote:
>>> +typedef void QemuLockGuardFunc(void *);
>>> +typedef struct QemuLockGuard {
>>> +QemuLockGuardFunc *p_lock_fn, *p_unlock_fn;
>>> +void *lock;
>>> +int locked;
>>
>> bool?
>
> Yes.
>
>>> +#define QEMU_WITH_LOCK(type, name, lock)
On 12/05/2017 02:10 AM, Thomas Huth wrote:
> The same definitions can also be found in include/hw/ide/ahci.h
> so let's remove these #defines from ahci_internal.h.
>
> Signed-off-by: Thomas Huth
> ---
> v2: Also remove TYPE_ICH9_AHCI as suggested by John
>
> hw/ide/ahci_internal.h | 12 -
On 12/08/2017 12:12 PM, Paolo Bonzini wrote:
> On 08/12/2017 16:13, Stefan Hajnoczi wrote:
>>> -qemu_mutex_lock(&pool->lock);
>>> +QEMU_LOCK_GUARD(QemuMutex, pool_guard, &pool->lock);
>>> if (pool->idle_threads == 0 && pool->cur_threads < pool->max_threads) {
>>> spawn_thread(
On 12/08/2017 07:10 AM, Anton Nefedov wrote:
> ATA8-ACS3, 7.9 DATA SET MANAGEMENT - 06h, DMA
>
> 7.9.5 Error Outputs
> If the Trim bit is set to one and:
> a) the device detects an invalid LBA Range Entry; or
> b) count is greater than IDENTIFY DEVICE data word 105
>
On 12/08/2017 09:13 AM, Stefan Hajnoczi wrote:
> On Fri, Dec 08, 2017 at 11:55:53AM +0100, Paolo Bonzini wrote:
>> @@ -88,9 +88,9 @@ static void *worker_thread(void *opaque)
>>
>> do {
>> pool->idle_threads++;
>> -qemu_mutex_unlock(&pool->lock);
>> +q
On 12/08/2017 04:55 AM, Paolo Bonzini wrote:
> This is an attempt to make a C API that resembles the C++
> std::unique_lock (mostly untested). The idea is that you can write
>
> QEMU_LOCK_GUARD(QemuMutex, guard_name, &some_mutex);
>
> instead of
>
> qemu_mutex_lock(&some_mutex);
> .
On 12/07/2017 06:58 PM, Marc-André Lureau wrote:
> $ make print-CFLAGS
> CFLAGS=-fsanitize=address -Og -g
>
> Trick from various sources:
> https://stackoverflow.com/questions/16467718/how-to-print-out-a-variable-in-makefile
> https://www.cmcrossroads.com/article/printing-value-makefile-variable
>
On 12/07/2017 06:58 PM, Marc-André Lureau wrote:
> In particular, do not print anything when there is nothing to do, in
> particular, after a successful build:
Do we need both 'in particular'?
>
> $ make
> make[1]: '/home/elmarco/src/qemu/build/capstone/libcapstone.a' is up to date.
>
> Signed-
On 12/07/2017 02:34 PM, Alberto Garcia wrote:
> On Thu 07 Dec 2017 08:16:41 PM CET, Eric Blake wrote:
>>> qemu_io('-f', iotests.imgfmt,
>>> -'-c', 'write -P %d %d %d' % (i, i*1024*1024, num_kb *
>>> 1024),
>>> +'-c', 'write -P 0xFF %dk %dk' %
On 11/30/2017 11:47 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.h | 34 +-
> block/qcow2.c | 16
> 2 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/block/qcow2.h b/
If you do two identical installs with qcow2 and raw, do you see any
differences with qemu-img compare afterwards that might indicate what
could possibly have gone wrong?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.lau
On Fri, Dec 8, 2017 at 12:49 PM, Peter Maydell wrote:
> Now that the 2.11 release is mostly out of the way, I've been
> working through some of my other todo list items so I've
> come back to this thread.
>
> My suggestion is that we should add a second non-secure UART
> to the virt board, so if y
On 12/06/2017 12:53 PM, Stefan Berger wrote:
> On 12/06/2017 02:26 AM, Cédric Le Goater wrote:
>> Hello Stefan,
>>
>> Some comments below. How do we populate the device tree ?
>
> Patched SLOF.
Ah. Isn't that a problem ? I thought QEMU was in charge of populating
the device tree.
>>
>> Thanks,
On 08/12/2017 16:13, Stefan Hajnoczi wrote:
>> -qemu_mutex_lock(&pool->lock);
>> +QEMU_LOCK_GUARD(QemuMutex, pool_guard, &pool->lock);
>> if (pool->idle_threads == 0 && pool->cur_threads < pool->max_threads) {
>> spawn_thread(pool);
>> }
>> QTAILQ_INSERT_TAIL(&pool->
Marc-André Lureau writes:
> Direct leak of 913 byte(s) in 43 object(s) allocated from:
> #0 0x55880a15df60 in __interceptor_malloc
> (/home/elmarco/src/qq/build/tests/qmp-test+0x110f60)
> #1 0x7f3f20fd098f in _IO_vasprintf (/lib64/libc.so.6+0x8098f)
>
> Signed-off-by: Marc-André Lureau
Marc-André Lureau writes:
> /public/qobject_is_equal_conversion: OK
>
> =
> ==14396==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 56 byte(s) in 1 object(s) allocated from:
> #0 0x7f07682c5850 in malloc (/lib64/l
Marc-André Lureau writes:
> Signed-off-by: Marc-André Lureau
> ---
> tests/Makefile.include | 3 +++
> tests/qapi-schema/enum-dict-member-invalid.err | 1 +
> tests/qapi-schema/enum-dict-member-invalid.exit | 1 +
> tests/qapi-schema/enum-dict-member-invalid.json |
On Fri, Dec 08, 2017 at 06:32:03PM +0100, Igor Mammedov wrote:
> On Fri, 8 Dec 2017 14:14:22 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> > > On Fri, 8 Dec 2017 13:19:27 +
> > > Peter Maydell wrote:
> > >
> > > > On 8 December 2017
On 08/12/2017 16:30, Stefan Hajnoczi wrote:
> On Fri, Dec 08, 2017 at 11:55:50AM +0100, Paolo Bonzini wrote:
>
> The implementation is somewhat complex. Please structure the header
> file so the public interfaces are clear and documented. Move the
> implementation out of the way and mark it priv
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Thu, 7 Dec 2017 18:17:51 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > vhost_verify_ring_mappings() were used to verify that
> > > rings are still accessible and related memory hasn't
> > > been m
On Fri, Dec 8, 2017 at 6:28 PM, Markus Armbruster wrote:
> Ladi Prosek writes:
>
>> On Fri, Dec 8, 2017 at 2:36 PM, Markus Armbruster wrote:
>>> Ladi Prosek writes:
>>>
The effects of ivshmem_enable_irqfd() was not undone on device reset.
This manifested as:
ivshmem_add_kvm_
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> Allow user to specify name for new export, to not reuse internal
> node name and to not show it to clients.
>
> This also allows creating several exports per device.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qapi/b
On Fri, 8 Dec 2017 14:14:22 -0200
Eduardo Habkost wrote:
> On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> > On Fri, 8 Dec 2017 13:19:27 +
> > Peter Maydell wrote:
> >
> > > On 8 December 2017 at 13:16, Igor Mammedov wrote:
> > > > TBH:
> > > > I do not recall why we
Ladi Prosek writes:
> On Fri, Dec 8, 2017 at 2:36 PM, Markus Armbruster wrote:
>> Ladi Prosek writes:
>>
>>> The effects of ivshmem_enable_irqfd() was not undone on device reset.
>>>
>>> This manifested as:
>>> ivshmem_add_kvm_msi_virq: Assertion `!s->msi_vectors[vector].pdev' failed.
>>>
>>> w
On 12/08/2017 09:30 AM, Max Reitz wrote:
> On 2017-12-05 01:48, John Snow wrote:
>>
>>
>> On 12/04/2017 05:21 PM, Max Reitz wrote:
>>> On 2017-12-04 23:15, John Snow wrote:
On 12/01/2017 02:41 PM, Max Reitz wrote:
> ((By the way, I don't suppose that's how it should work... Bu
On 12/08/2017 10:14 AM, Peter Lieven wrote:
> Am 08.12.2017 um 16:11 schrieb Eric Blake:
>> On 12/08/2017 05:51 AM, Peter Lieven wrote:
>>> we currently report an "iSCSI Failure" in iscsi_co_generic_cb if the task
>>> hasn't completed with SCSI_STATUS_GOOD. However, we expect a failure in
>>> some
SPARC Linux has an oddity that it insists that mmap()
of MAP_FIXED memory must be at an alignment defined by
SHMLBA, which is more aligned than the page size
(typically, SHMLBA alignment is to 16K, and pages are 8K).
This is a relic of ancient hardware that had cache
aliasing constraints, but even
We are good enough to boot upstream Linux kernels / Fedora 26/27. That
should be sufficient for now.
As the QEMU CPU model is migration safe, let's add compatibility code.
Generate the feature list to reduce the chance of messing things up in the
future.
Signed-off-by: David Hildenbrand
---
hw/
On 08.12.2017 17:34, Daniel P. Berrange wrote:
> On Fri, Dec 08, 2017 at 05:29:36PM +0100, David Hildenbrand wrote:
>> On 08.12.2017 17:26, Cornelia Huck wrote:
>>> On Fri, 8 Dec 2017 17:02:07 +0100
>>> David Hildenbrand wrote:
>>>
We are good enough to boot upstream Linux kernels / Fedora 2
On Fri, Dec 08, 2017 at 05:29:36PM +0100, David Hildenbrand wrote:
> On 08.12.2017 17:26, Cornelia Huck wrote:
> > On Fri, 8 Dec 2017 17:02:07 +0100
> > David Hildenbrand wrote:
> >
> >> We are good enough to boot upstream Linux kernels / Fedora 26/27. That
> >> should be sufficient for now.
> >
Am 06.12.2017 um 11:53 hat Kevin Wolf geschrieben:
> I was looking into the drain functions in order to develop them a bit in
> the direction that Fam suggested, to unify the code between bdrv_drain()
> and bdrv_drain_all() a bit more, and maybe to find a place to take
> coroutine locks for graph c
On 08.12.2017 17:26, Cornelia Huck wrote:
> On Fri, 8 Dec 2017 17:02:07 +0100
> David Hildenbrand wrote:
>
>> We are good enough to boot upstream Linux kernels / Fedora 26/27. That
>> should be sufficient for now.
>>
>> As the QEMU CPU model is migration safe, let's add compatibility code.
>> Ge
On Fri, 8 Dec 2017 17:02:07 +0100
David Hildenbrand wrote:
> We are good enough to boot upstream Linux kernels / Fedora 26/27. That
> should be sufficient for now.
>
> As the QEMU CPU model is migration safe, let's add compatibility code.
> Generate the feature list to reduce the chance of mess
On 12/08/2017 07:44 AM, Ladi Prosek wrote:
>>> static void ivshmem_write_config(PCIDevice *pdev, uint32_t address,
>>> uint32_t val, int len)
>>> {
>>
>> Why are you moving ivshmem_reset()? Makes the actual change harder to
>> see than necessary.
>
> ivshmem_d
On Fri, Dec 08, 2017 at 10:21:35AM -0600, Eric Blake wrote:
> On 12/08/2017 07:34 AM, Daniel P. Berrange wrote:
> > qemu-io puts the TTY into non-canonical mode, which means no EOF processing
> > is
> > done and thus getchar() will never return the EOF constant. Instead we have
> > to
> > query t
On 12/08/2017 07:34 AM, Daniel P. Berrange wrote:
> qemu-io puts the TTY into non-canonical mode, which means no EOF processing is
> done and thus getchar() will never return the EOF constant. Instead we have to
> query the TTY attributes to determine the configured EOF character (usually
> Ctrl-D
On Fri, Dec 8, 2017 at 2:27 PM, Michael S. Tsirkin wrote:
> On Fri, Dec 08, 2017 at 06:08:05AM +, Stefan Hajnoczi wrote:
>> On Thu, Dec 7, 2017 at 11:54 PM, Michael S. Tsirkin wrote:
>> > On Thu, Dec 07, 2017 at 06:28:19PM +, Stefan Hajnoczi wrote:
>> >> On Thu, Dec 7, 2017 at 5:38 PM, Mi
On 12/08/2017 05:58 AM, Daniel P. Berrange wrote:
> The current docs for TLS assume only VNC is using TLS. Some of the information
> is also outdated (ie lacking subject alt name info for certs). Rewrite it to
> more accurately reflect the current situation.
>
> Signed-off-by: Daniel P. Berrange
On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> On Fri, 8 Dec 2017 13:19:27 +
> Peter Maydell wrote:
>
> > On 8 December 2017 at 13:16, Igor Mammedov wrote:
> > > TBH:
> > > I do not recall why we have x86 max/host cpu types do feature
> > > loading at realize time instead
Am 08.12.2017 um 16:11 schrieb Eric Blake:
> On 12/08/2017 05:51 AM, Peter Lieven wrote:
>> we currently report an "iSCSI Failure" in iscsi_co_generic_cb if the task
>> hasn't completed with SCSI_STATUS_GOOD. However, we expect a failure in
>> some cases and handle it gracefully. This is the case f
On Fri 08 Dec 2017 02:47:52 PM CET, Max Reitz wrote:
> +static void curl_refresh_filename(BlockDriverState *bs)
> +{
> +BDRVCURLState *s = bs->opaque;
> +
> +if (!s->sslverify || s->cookie ||
> +s->username || s->password || s->proxyusername ||
> s->pr
We are good enough to boot upstream Linux kernels / Fedora 26/27. That
should be sufficient for now.
As the QEMU CPU model is migration safe, let's add compatibility code.
Generate the feature list to reduce the chance of messing things up in the
future.
Signed-off-by: David Hildenbrand
---
hw/
It only provides the EXTRACT CPU TIME instruction. We can reuse the stpt
helper, which calculates the CPU timer value.
As the instruction is not privileged, but we don't have a CPU timer
value in case of linux user, we simply reuse cpu_get_host_ticks() to
produce some descending value.
Signed-off
Just like KVM does, we should suppress this instruction:
When this instruction is not provided, it is
checked for privileged operation exception and the
instruction is suppressed by the machine
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-dat
Let's just wire it up like KVM.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 1 +
target/s390x/misc_helper.c | 9 +
target/s390x/translate.c | 7 +++
4 files changed, 18 insertions(+)
diff --git
KVM suppresses SIGA, setting cc=3. Let's do the same for TCG, so we're at
least equal.
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 1 +
target/s390x/translate.c | 8
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-
The Set-Program-Parameter facility (also known as Load-Program-Parameter
facility) provides the LPP instruction used to load the program
parameter. We already implement that instruction in TCG, so add it to our
list.
Note: Not documented in the PoP but in "The Load-Program-Parameter and
CPU-Measur
Let's handle it just like KVM:
Depending on the model, this instruction may not be
provided. When this instruction is not provided, it is
checked for operand exception and privileged-opera-
tion exception, and then is suppressed.
Reviewed-by: Richard Henderson
Signed-off-by: David
With this facility, OI/OIY, NI/NIY and XI/XIY are atomic. All operate on
one byte (MO_UB). Emulate old behavior.
Signed-off-by: David Hildenbrand
---
target/s390x/cpu_models.c | 1 +
target/s390x/insn-data.def | 12 -
target/s390x/translate.c | 63
The semantics of ASI/ASGI/ALSI/ALSGI changed. Let's implement them just
like LOAD AND ADD, so they are atomic. Emulate old behavior.
This fixes random crashes when booting a Linux kernel compiled for
z196+ with SMP + MTTCG.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 8 ++
CRW machine check handling requires STCRW. So let's wire it up.
Reviewed-by: Thomas Huth
Reviewed-by: Richard Henderson
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 1 +
target/s390x/misc_helper.c | 9 +
target/s390x/translate.c
Needed for machine check handling inside Linux (when restoring registers).
Except for SIGP and machine checks, we don't make use of the register
yet. Sufficient for now.
Reviewed-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def
Both series in one piece as (most probably) most reviewing is done.
Wire up some io instructions and implement new facilitites. Make sure
to take care of MTTCG when it comes to atomic operations. Make CCW
hotplug work.
As we are now able to install/boot a Fedora 26/27 as well as an upstream
kerne
The architecture mode indication wasn't stored. The split of certain
64bit fields was unnecessary. Also, the complete clock comparator, not
just bit 0-55 (starting at byte 1) was stored.
We now generate a proper MCIC via the same helper we use for KVM.
There is more to clean up, but we will chang
We were not yet using the value of the TOD Programmable Register.
Reviewed-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
target/s390x/translate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index d13f531c5b..38e1770e5e 1006
We'll need it later on in two places. Refactor it to just indicate the
validity bits. While at it, introduce a define for the used CR14 bit (we'll
also need later on).
Signed-off-by: David Hildenbrand
---
target/s390x/cpu.h | 23 +++
target/s390x/kvm.c | 25 ++
Depending on the configuration, it can be beneficial to adjust the virtio-blk
queue size to something other than the current default of 128. Add a new
property to make the queue size configurable.
Signed-off-by: Mark Kanda
Reviewed-by: Karl Heubaum
Reviewed-by: Martin K. Petersen
Reviewed-by: A
virtio-blk logical block size should never be larger than physical block
size because it doesn't make sense to have such configurations. QEMU doesn't
have a way to effectively express this condition; the best it can do is
report the physical block exponent as 0 - indicating the logical block size
e
v2: add check for maximum queue size [Stefan]
This series is for two minor virtio-blk changes. The first patch
makes the virtio-blk queue size user configurable. The second patch
rejects logical block size > physical block configurations (similar
to a recent change in virtio-scsi).
Mark Kanda (2)
Public bug reported:
Windows NT 4.0 will not boot from an installation more than once if
installed in a qcow2 image file. A quick fix to this problem is to use
the qcow format instead.
Steps to reproduce this issue:
Create the image file:
qemu-img create -f qcow2 winnt4.qcow2 1G
Boot from a Win
On Wed, Dec 06, 2017 at 02:45:41PM +, Stefan Hajnoczi wrote:
> v2:
> * Use StrOrNull for x-blockdev-set-iothread iothread argument [eblake]
>
> (This is for QEMU 2.12 because this bug is not -rc4 critical)
>
> Previously AioContext was held across QMP 'transaction' in an attempt to
> achieve
On Fri, Dec 08, 2017 at 11:55:50AM +0100, Paolo Bonzini wrote:
The implementation is somewhat complex. Please structure the header
file so the public interfaces are clear and documented. Move the
implementation out of the way and mark it private. That will make it
easier for someone to figure o
On 12/06/2017 04:53 AM, Kevin Wolf wrote:
> This adds a test case that the BlockDriver callbacks for drain are
> called in bdrv_drained_all_begin/end(), and that both of them are called
> exactly once.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/test-bdrv-drain.c | 137
> +++
On Fri, Dec 08, 2017 at 11:55:53AM +0100, Paolo Bonzini wrote:
> @@ -88,9 +88,9 @@ static void *worker_thread(void *opaque)
>
> do {
> pool->idle_threads++;
> -qemu_mutex_unlock(&pool->lock);
> +qemu_lock_guard_unlock(&pool_guard);
> ret
Add virt-2.12 machine type.
Signed-off-by: Peter Maydell
---
include/hw/compat.h | 3 +++
hw/arm/virt.c | 19 +--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/hw/compat.h b/include/hw/compat.h
index cf389b4..263de97 100644
--- a/include/hw/compat
On 12/08/2017 07:02 AM, David Hildenbrand wrote:
> +/* Store CPU Timer (also used for EXTRACT CPU TIME) */
> +uint64_t HELPER(stpt)(CPUS390XState *env)
> +{
> +#if defined(CONFIG_USER_ONLY)
> +/*
> + * Fake a descending CPU timer. We could get negative values here,
> + * but we don't ca
1 - 100 of 207 matches
Mail list logo
