On Tue, Jan 29, 2019 at 07:56:54AM +0100, Philippe Mathieu-Daudé wrote:
>Hi Wei,
>
>On 1/29/19 1:08 AM, Wei Yang wrote:
>> There are several functions/variable which are not used anymore.
>>
>> This serials just remove those without functional change.
>>
>> Wei Yang (3):
>> hw/i386/pc.c: remove
On Fri, 25 Jan 2019 16:00:58 -0500
Stefan Berger wrote:
> This patch makes the a TPM 2.0 with TIS interface available under the
> HID 'MSF0101'. This is supported by Linux and also Windows now
> recognizes the TPM 2.0 with TIS interface. Leave the TPM 1.2 as before.
>
> Signed-off-by: Stefan Ber
On 28/01/19 19:02, Peter Maydell wrote:
>
> I don't understand why the build/config-all-devices.mak versions of
> the defines of CONFIG_FOO variables are so weird:
>
> CONFIG_ACPI:=$(findstring y,$(CONFIG_ACPI)y)
>
> ...are they really intended to be self-referential like that?
Yes, config-all-
On 1/29/19 9:04 AM, Wei Yang wrote:
> On Tue, Jan 29, 2019 at 07:56:54AM +0100, Philippe Mathieu-Daudé wrote:
>> Hi Wei,
>>
>> On 1/29/19 1:08 AM, Wei Yang wrote:
>>> There are several functions/variable which are not used anymore.
>>>
>>> This serials just remove those without functional change.
>
On 1/29/19 1:08 AM, Wei Yang wrote:
> Function pc_acpi_init() is not used anymore.
>
> Remove the definition and declaration.
>
> Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
> ---
> hw/i386/pc.c | 27 ---
> in
On 1/29/19 1:08 AM, Wei Yang wrote:
> Function acpi_table_add_builtin() is not used anymore.
>
> Remove the definition and declaration.
>
> Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
> ---
> hw/acpi/core.c | 6 --
> include/hw/a
On 1/29/19 1:08 AM, Wei Yang wrote:
> acpi_table_builtin is now always false, it is not necessary to check it
> again.
>
> This patch just removes it.
>
> Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
> ---
> hw/acpi/core.c | 4 +---
> 1 file
On Tue, Jan 29, 2019 at 11:58:01AM +0530, Pankaj Gupta wrote:
> Hotplugging existing char chardev with qmp, dereferences(removes)
> existing chardev. This patch avoids adding a chardev if a chardev
> with same id exists.
>
> RH BZ 1660831:
>
> # (host) ls -lt /tmp/helloworld*
> srwxr-xr-x. /t
Due to a misuse of rules.mak logical functions, commit f386df17448
disabled the guest-agent test.
Enable it back.
Signed-off-by: Philippe Mathieu-Daudé
---
>From rules.mak:
# Logical functions (for operating on y/n values like CONFIG_FOO vars)
# Usage: $(call land,$(CONFIG_FOO),$(CONFIG_BAR)
On 29/01/2019 09:23, Philippe Mathieu-Daudé wrote:
> On 1/29/19 9:04 AM, Wei Yang wrote:
>> On Tue, Jan 29, 2019 at 07:56:54AM +0100, Philippe Mathieu-Daudé wrote:
>>> Hi Wei,
>>>
>>> On 1/29/19 1:08 AM, Wei Yang wrote:
There are several functions/variable which are not used anymore.
On 1/28/2019 10:48 PM, Eduardo Habkost wrote:
On Mon, Jan 28, 2019 at 04:33:40PM +0800, Tao Xu wrote:
On 1/24/2019 3:15 AM, Eduardo Habkost wrote:
On Mon, Jan 21, 2019 at 05:29:32PM +0800, Tao Xu wrote:
On 1/15/2019 2:35 AM, Eduardo Habkost wrote:
Sorry, we do have a problem here:
On Thu, De
On 2019-01-29 09:38, Philippe Mathieu-Daudé wrote:
> Due to a misuse of rules.mak logical functions, commit f386df17448
> disabled the guest-agent test.
> Enable it back.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> From rules.mak:
>
> # Logical functions (for operating on y/n values like
On Tue, 29 Jan 2019 08:32:08 +0100
Philippe Mathieu-Daudé wrote:
> Hi Zoltan,
>
> On 1/29/19 2:20 AM, BALATON Zoltan wrote:
> > Hello,
> >
> > I'm getting error building on macOS after commit ddac19f534:
> >
> > CC aarch64-softmmu/hw/virtio/virtio-blk-pci.o
> > In file included from qem
On 2019-01-28 17:08, Cornelia Huck wrote:
> On Mon, 28 Jan 2019 16:29:26 +0100
> Thomas Huth wrote:
>
>> Instead of hard-coding all config switches in the config file
>> default-configs/s390x-softmmu.mak, let's use the new Kconfig files
>> to express the necessary dependencies: The S390_CCW_VIRTI
On 29/01/2019 09:38, Philippe Mathieu-Daudé wrote:
> Due to a misuse of rules.mak logical functions, commit f386df17448
> disabled the guest-agent test.
> Enable it back.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> From rules.mak:
>
> # Logical functions (for operating on y/n values like
Instead of hard-coding all config switches in the config file
default-configs/s390x-softmmu.mak, let's use the new Kconfig files
to express the necessary dependencies: The S390_CCW_VIRTIO config switch
for the "s390-ccw-virtio" machine now selects all non-optional devices.
And since we already hav
On Mon, Jan 28, 2019 at 17:55:14 +0100, Markus Armbruster wrote:
> Kevin Wolf writes:
>
> > Am 28.01.2019 um 09:50 hat Peter Krempa geschrieben:
> [...]
> >> 2) Is actually using 'scsi-cd'/'scsi-hd' the better option than
> >> 'scsi-disk'?
> >
> > Yes, scsi-disk is a legacy device. Maybe we shoul
On Tue, 29 Jan 2019 10:42:14 +0100
Thomas Huth wrote:
> Instead of hard-coding all config switches in the config file
> default-configs/s390x-softmmu.mak, let's use the new Kconfig files
> to express the necessary dependencies: The S390_CCW_VIRTIO config switch
> for the "s390-ccw-virtio" machine
Add the Altera JTAG UART model.
Hardware emulation based on:
https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
(Please see "Register Map" on page 65)
Signed-off-by: Juro Bystricky
Acked-by: Marek Vasut
Tested-by: Tobias Klauser
Signed-off-by: Tobias Klauser
---
Re-submit of
Am 28.01.2019 um 21:01 hat Andrey Shinkevich geschrieben:
> In the 'Format specific information' section of the 'qemu-img info'
> command output, the supplemental information about existing QCOW2
> bitmaps will be shown, such as a bitmap name, flags and granularity:
>
> image: /vz/vmprivate/VM1/ha
Am 28.01.2019 um 21:01 hat Andrey Shinkevich geschrieben:
> A new test file 239 added to the qemu-iotests set. It checks
> the output format of 'qemu-img info' for bitmaps extension of
> qcow2 specific information.
>
> Signed-off-by: Andrey Shinkevich
Can you add human output to the test, too?
On Mon, 28 Jan 2019 at 21:08, Richard Henderson
wrote:
>
> On 1/22/19 5:26 AM, Peter Maydell wrote:
> >> +guarded |= extract64(descriptor, 50, 1); /* GP */
> >
> > Do we need to do the logical-OR here? Since this is a
> > block/page entry bit with no similar bit in the table
> > descripto
On Tue, 29 Jan 2019 at 03:55, Stefan Hajnoczi wrote:
>
> On Fri, Jan 25, 2019 at 02:03:39PM -, Christophe Lyon wrote:
> > I've just realized that after I reconfigured my qemu with
> > ../configure
> > --target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user
> > --enable-tr
On Mon, 28 Jan 2019 at 21:28, Richard Henderson
wrote:
>
> On 1/22/19 6:12 AM, Peter Maydell wrote:
> > On Thu, 10 Jan 2019 at 12:17, Richard Henderson
> > wrote:
> >>
> >> This is all of the non-exception cases of DISAS_NORETURN.
> >
> > What about the gen_helper_exit_atomic() exit cases ?
>
> I
On Mon, 28 Jan 2019 20:30:00 +0100
Halil Pasic wrote:
> On Mon, 28 Jan 2019 18:13:55 +0100
> Cornelia Huck wrote:
>
> > On Fri, 25 Jan 2019 17:04:04 +0100
> > Halil Pasic wrote:
> >
> > > Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> > > today, or is this supposed
On Mon 28 Jan 2019 07:38:08 PM CET, Markus Armbruster wrote:
>> 093 submits several I/O requests using aio_read and aio_write with
>> hmp_qemu_io(), then advances the clock using clock_step and finally
>> calls query-blockstats to see how much of the I/O has been completed
>> (it's an I/O throttli
On Tue, 29 Jan 2019 at 04:56, Max Filippov wrote:
>
> Hello,
>
> On Fri, Dec 7, 2018 at 1:04 AM Luc Michel wrote:
> >
> > Change the thread info related packets handling to support multiprocess
> > extension.
> >
> > Add the CPUs class name in the extra info to help differentiate
> > them in mult
On 29/01/19 10:49, Cornelia Huck wrote:
> On Tue, 29 Jan 2019 10:42:14 +0100
> Thomas Huth wrote:
>
>> Instead of hard-coding all config switches in the config file
>> default-configs/s390x-softmmu.mak, let's use the new Kconfig files
>> to express the necessary dependencies: The S390_CCW_VIRTIO
On Mon, 28 Jan 2019 20:15:48 +0100
Halil Pasic wrote:
> On Mon, 28 Jan 2019 18:09:48 +0100
> Cornelia Huck wrote:
>
> > On Fri, 25 Jan 2019 15:01:01 +0100
> > Halil Pasic wrote:
> >
> > > On Fri, 25 Jan 2019 13:58:35 +0100
> > > Cornelia Huck wrote:
> >
> > > > - The code should not b
On Tue, 29 Jan 2019 at 08:21, Paolo Bonzini wrote:
>
> On 28/01/19 19:02, Peter Maydell wrote:
> >
> > I don't understand why the build/config-all-devices.mak versions of
> > the defines of CONFIG_FOO variables are so weird:
> >
> > CONFIG_ACPI:=$(findstring y,$(CONFIG_ACPI)y)
> >
> > ...are they
On Tue, 29 Jan 2019 at 09:51, Tobias Klauser wrote:
>
> Add the Altera JTAG UART model.
>
> Hardware emulation based on:
> https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
> (Please see "Register Map" on page 65)
>
> Signed-off-by: Juro Bystricky
> Acked-by: Marek Vasut
> Teste
On Mon, 28 Jan 2019 16:48:10 -0500
Eric Farman wrote:
> On 01/28/2019 02:15 PM, Halil Pasic wrote:
> > On Mon, 28 Jan 2019 18:09:48 +0100
> > Cornelia Huck wrote:
> I guess if
> > the ssch() returns with non cc == 0 the CP_PENDING ---IRQ---> IDLE
> > transition
> > won't take place. And I guess
On Tue, 29 Jan 2019, Philippe Mathieu-Daudé wrote:
On 1/29/19 2:20 AM, BALATON Zoltan wrote:
Hello,
I'm getting error building on macOS after commit ddac19f534:
? CC? aarch64-softmmu/hw/virtio/virtio-blk-pci.o
In file included from qemu/hw/virtio/virtio-9p-pci.c:19:
In file included from q
>>> I'm wondering what the architecture says regarding those events -- can
>>> someone with access to the documentation comment?
>>
>> Ping. Any comments from the IBM folks?
>>
>
>
> So the idea here is that if we have a PCI device that is the process of
> being deconfigured and we are also in t
29.01.2019 6:31, Stefan Hajnoczi wrote:
> On Fri, Jan 25, 2019 at 07:46:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all.
>>
>> What about such a simple helper for a very often patter around
>> qemu_iovec_init_external ?
>
> Sounds good, qemu_iovec_init() has 55 references vs
> qemu_iovec
On 2019-01-29 at 11:19:02 +0100, Peter Maydell wrote:
> On Tue, 29 Jan 2019 at 09:51, Tobias Klauser wrote:
> >
> > Add the Altera JTAG UART model.
> >
> > Hardware emulation based on:
> > https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
> > (Please see "Register Map" on page 65
On Tue, Jan 29, 2019 at 6:24 PM Vladimir Sementsov-Ogievskiy
wrote:
> 29.01.2019 6:31, Stefan Hajnoczi wrote:
> > On Fri, Jan 25, 2019 at 07:46:01PM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> Hmm. In this case we definitely will have tiny extra memory usage, but we
> gain beautiful
> reada
On Tue, 29 Jan 2019 at 10:36, Daniel P. Berrangé wrote:
> On Thu, Jan 24, 2019 at 06:56:09PM +, Peter Maydell wrote:
> > (1) configure: My thought is that we should just make
> > sphinx-build a requirement for the existing --enable-docs
> > switch (as texinfo and pod2man are currently). The
>
On Tue, Jan 29, 2019 at 10:53:43AM +0800, Stefan Hajnoczi wrote:
> Autogenerated code in trace.h/trace.c and friends is specific to the
> config-host.mak TRACE_BACKENDS setting and must be regenerated when
> ./configure --enable-trace-backend= changes settings.
>
> This patch ensures that changes
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Mon, Jan 28, 2019 at 05:03:21PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > We now expose qemu_announce_self through QMP and HMP. Add a test
> > with some very basic packet validation (make sure we get a
On Thu, Jan 24, 2019 at 06:56:09PM +, Peter Maydell wrote:
> I had another look this afternoon at building our rST docs
> with sphinx-build. In particular, we currently have some
> docs in rst format, but we're not building them into HTML
> or shipping them. (Predictably, this means a few error
Intel Processor Trace required CPUID[0x14] but the cpuid_level
have no change when create a kvm guest with
e.g. "-cpu qemu64,+intel-pt".
Signed-off-by: Luwei Kang
---
hw/i386/pc.c | 1 +
target/i386/cpu.c | 9 +
target/i386/cpu.h | 3 +++
3 files changed, 13 insertions(+)
diff --gi
Intel Processor Trace required CPUID[0x14] but the cpuid_level
have no change when create a kvm guest with
e.g. "-cpu qemu64,+intel-pt".
Signed-off-by: Eduardo Habkost
Signed-off-by: Luwei Kang
---
hw/i386/pc.c | 1 +
target/i386/cpu.c | 9 +
target/i386/cpu.h | 3 +++
3 files chan
> -Original Message-
> From: Kang, Luwei
> Sent: Wednesday, January 30, 2019 7:53 AM
> To: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> r...@twiddle.net; ehabk...@redhat.com
> Cc: qemu-devel@nongnu.org; Kang, Luwei
> Subject: [PATCH V2] i386: extended the cpuid_leve
Am 24.01.2019 um 16:56 hat Eric Blake geschrieben:
> On 1/24/19 8:17 AM, Kevin Wolf wrote:
> > Depending on the exact image layout and the storage backend (tmpfs is
> > konwn to have very slow SEEK_HOLE/SEEK_DATA), caching lseek results can
> > save us a lot of time e.g. during a mirror block job o
On Tue, 29 Jan 2019, BALATON Zoltan wrote:
On Tue, 29 Jan 2019, Philippe Mathieu-Daudé wrote:
On 1/29/19 2:20 AM, BALATON Zoltan wrote:
Hello,
I'm getting error building on macOS after commit ddac19f534:
? CC? aarch64-softmmu/hw/virtio/virtio-blk-pci.o
In file included from qemu/hw/virtio
Hi,
Following up on yesterday's discussion on IRC I thought I'd better
report on my findings in the permanent record so things don't get lost.
As I tend to periodically rebuild my test kernels from the current
state of linux.git I occasionally run into these things. My test
invocation is:
qe
On Tue, Jan 29, 2019 at 11:07:19AM +0100, Paolo Bonzini wrote:
> On 29/01/19 10:49, Cornelia Huck wrote:
> > On Tue, 29 Jan 2019 10:42:14 +0100
> > Thomas Huth wrote:
> >
> >> Instead of hard-coding all config switches in the config file
> >> default-configs/s390x-softmmu.mak, let's use the new K
29.01.2019 13:32, Stefan Hajnoczi wrote:
> On Tue, Jan 29, 2019 at 6:24 PM Vladimir Sementsov-Ogievskiy
> wrote:
>> 29.01.2019 6:31, Stefan Hajnoczi wrote:
>>> On Fri, Jan 25, 2019 at 07:46:01PM +0300, Vladimir Sementsov-Ogievskiy
>>> wrote:
>> Hmm. In this case we definitely will have tiny extra
* Eric Blake (ebl...@redhat.com) wrote:
> On 1/28/19 11:03 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > The 'announce timer' will be used by migration, and explicit
> > requests for qemu to perform network announces.
> >
> > Based on the work by Germano Veit
Responding to an old thread ...
On Thu, 15 Nov 2018 at 17:05, Peter Maydell wrote:
>
> On 19 October 2018 at 09:55, Hongbo Zhang wrote:
> > For the Aarch64, there is one machine 'virt', it is primarily meant to
> > run on KVM and execute virtualization workloads, but we need an
> > environment a
Hi, Wainer.
On Mon, Jan 28, 2019 at 05:42:24PM -0200, Wainer dos Santos Moschetta wrote:
>
> On 01/28/2019 03:47 PM, Caio Carrara wrote:
> > This change adds the possibility to write acceptance tests with multi
> > virtual machine support. It's done keeping the virtual machines objects
> > stored
* Eric Blake (ebl...@redhat.com) wrote:
> On 1/28/19 11:03 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Add migration parameters that control RARP/GARP announcement timeouts.
> >
> > Based on earlier patches by myself and
> > Vladislav Yasevich
> >
> > S
This is a few misc fixes identified after the icon location changes
were merged. Most importantly it deals with the nsis installer file
manifest.
Daniel P. Berrangé (5):
nsis: don't install files into /tmp
make: don't insert a '/' after $(DESTDIR)
nsis: ensure we always pass -W64 flag to nsi
The nsis installer target has to run 'make install' to populate a
directory tree with content for the package. Replace the current
usage of '/tmp/qemu-nsis' with a location underneath the build
directory. This ensures that when a developer cleans their build
directory, any left over files from the
The icons were all moved from pci-bios to ui/icons with:
commit a8260d3876389eb52ca5c62ed4d80cdb7e025c85
Author: Daniel P. Berrangé
Date: Thu Jan 10 12:00:45 2019 +
ui: install logo icons to $prefix/share/icons
Adding symlinks from the source directory into the build dir
This breaks when $(prefix) is a relative directory, as it turns it
into an absolute path.
Signed-off-by: Daniel P. Berrangé
---
Makefile | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 362a98d275..14a463564e 100644
--- a/Makefile
+++
The code to set the -W64 flag is inside a conditional block that only
executes when we are bundling DLLs with the installer. This results in
QEMU being installed in the wrong location on 64-bit hosts when DLLs
are not bundled.
Signed-off-by: Daniel P. Berrangé
---
Makefile | 5 -
1 file chan
Hi Yiwen,
I'm currently interested on how to improve the VSOCK performance and I
read your discussions with Jason, Michael, and Stefan on both
linux-netdev and qemu-devel mailing lists.
Are you still working on it?
Reading the discussions I understood that batching can help us a lot
to increase t
The bmp icon files no longer exist in the root of the installation
tree. Instead we must reference the new icons subdirectory location
introduced in
commit a8260d3876389eb52ca5c62ed4d80cdb7e025c85
Author: Daniel P. Berrangé
Date: Thu Jan 10 12:00:45 2019 +
ui: install logo icons
On Mon, 28 Jan 2019 at 19:01, Peter Maydell wrote:
> This assertion fails on PPC64 hosts:
> ERROR:/home/pm215/qemu/tests/microbit-test.c:181:fill_and_erase:
> assertion failed (qtest_readl(qts, base + i * 4) == i): (16777216 ==
> 1)
For the moment I have dropped patches
hw/nvram/nrf51_nvm: Add n
On Mon, 28 Jan 2019 at 19:01, Peter Maydell wrote:
> This assertion fails on PPC64 hosts:
> ERROR:/home/pm215/qemu/tests/microbit-test.c:181:fill_and_erase:
> assertion failed (qtest_readl(qts, base + i * 4) == i): (16777216 ==
> 1)
>
> I suspect an endianness issue, given that 16777216 is 0x0100_
Hi,
[adding Kristina, who is in charge of Linux pointer authentication]
On Tue, Jan 29, 2019 at 11:08:19AM +, Alex Bennée wrote:
> Hi,
>
> Following up on yesterday's discussion on IRC I thought I'd better
> report on my findings in the permanent record so things don't get lost.
>
> As I te
* Eric Blake (ebl...@redhat.com) wrote:
> On 1/28/19 11:03 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Add a qmp command that can trigger guest announcements.
> >
> > It uses it's own announce-timer instance, and parameters
>
> s/it's/its/ (here, you want
On Tue, 29 Jan 2019 at 11:46, Mark Rutland wrote:
> On Tue, Jan 29, 2019 at 11:08:19AM +, Alex Bennée wrote:
> > The -cpu max enabled a cortex-a57 + whatever extra features we've
> > enabled in QEMU so far. It won't match any "real" CPU but it should be
> > architecturally correct in so far we
On Tue, 29 Jan 2019 at 11:39, Daniel P. Berrangé wrote:
> Inability to find icons during startup when not having run a
> "make install" is harmless, as frontends just continue without
> error. So it is not worth trying to add code hacks to find icons
> in non-installed directories.
I'm not hugely
8 16:26:47 +)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20190129
for you to fetch changes up to 46f5abc0a2566ac3dc954eeb62fd625f0eaca120:
gdbstub: Simplify gdb_get_cpu_pid() to use cpu->cluster_index (2019-01-29
1
>>
>> diff --git a/block/qapi.c b/block/qapi.c
>> index c66f949..0fde98c 100644
>> --- a/block/qapi.c
>> +++ b/block/qapi.c
>> @@ -38,6 +38,7 @@
>> #include "qapi/qmp/qstring.h"
>> #include "sysemu/block-backend.h"
>> #include "qemu/cutils.h"
>> +#include "qemu/error-report.h"
>>
>> Bloc
Alberto Garcia writes:
> On Mon 28 Jan 2019 07:38:08 PM CET, Markus Armbruster wrote:
>
>>> 093 submits several I/O requests using aio_read and aio_write with
>>> hmp_qemu_io(), then advances the clock using clock_step and finally
>>> calls query-blockstats to see how much of the I/O has been com
Until now, the set_pc logic was unclear, which raised questions about
whether it should be used directly, applying a value to PC or adding
additional checks, for example, set the Thumb bit in Arm cpu. Let's set
the set_pc logic for “Configure the PC, as was done in the ELF file”
and implement synch
On Wed, Jan 23, 2019 at 09:08:49AM +, Paul Durrant wrote:
> Some frontend drivers will handle dynamic resizing of PV disks, so set up
> the BlockDevOps resize_cb() method during xen_block_realize() to allow
> this to be done.
"will": which drivers are you thinking about? The Linux one seems to
On Tue, Jan 29, 2019 at 08:10:19 +0100, Markus Armbruster wrote:
> Kevin Wolf writes:
>
> > Am 28.01.2019 um 17:55 hat Markus Armbruster geschrieben:
> >> Kevin Wolf writes:
> >>
> >> > Am 28.01.2019 um 09:50 hat Peter Krempa geschrieben:
> >> [...]
> >> >> 2) Is actually using 'scsi-cd'/'scsi-
On 1/25/19 6:46 PM, Kevin Wolf wrote:
> scsi-disk includes in the Device Identification VPD page, depending on
> configuration amongst others, a vendor specific designator that consists
> either of the serial number if given or the BlockBackend name (which is
> a host detail that better shouldn't h
Am 29.01.2019 um 12:18 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 29.01.2019 13:32, Stefan Hajnoczi wrote:
> > On Tue, Jan 29, 2019 at 6:24 PM Vladimir Sementsov-Ogievskiy
> > wrote:
> >> 29.01.2019 6:31, Stefan Hajnoczi wrote:
> >>> On Fri, Jan 25, 2019 at 07:46:01PM +0300, Vladimir Sementso
Am 29.01.2019 um 13:04 hat Andrey Shinkevich geschrieben:
> >>
> >> diff --git a/block/qapi.c b/block/qapi.c
> >> index c66f949..0fde98c 100644
> >> --- a/block/qapi.c
> >> +++ b/block/qapi.c
> >> @@ -38,6 +38,7 @@
> >> #include "qapi/qmp/qstring.h"
> >> #include "sysemu/block-backend.h"
> >>
On Mon, 28 Jan 2019 16:32:38 +0100
Igor Mammedov wrote:
In the subject: s/form/from/
> I plan to deprecate -mem-path option and replace it with memory-backend,
> for that it's necessary to get rid of mem_path global variable.
> Do it for s390x case, replacing it with alternative way to enable
>
On 24/01/2019 10:53, Thomas Huth wrote:
It's either "GNU *Library* General Public version 2" or "GNU Lesser
General Public version *2.1*", but there was no "version 2.0" of the
Should the word "License" be after both instances of "Public" above ?
"Lesser" library. So assume that version 2.1 i
On Tue, Jan 29, 2019 at 11:54:13AM +, Peter Maydell wrote:
> On Tue, 29 Jan 2019 at 11:46, Mark Rutland wrote:
> > On Tue, Jan 29, 2019 at 11:08:19AM +, Alex Bennée wrote:
> > > The -cpu max enabled a cortex-a57 + whatever extra features we've
> > > enabled in QEMU so far. It won't match a
29.01.2019 15:38, Kevin Wolf wrote:
> Am 29.01.2019 um 13:04 hat Andrey Shinkevich geschrieben:
diff --git a/block/qapi.c b/block/qapi.c
index c66f949..0fde98c 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -38,6 +38,7 @@
#include "qapi/qmp/qstring.h"
29.01.2019 15:50, Vladimir Sementsov-Ogievskiy wrote:
> 29.01.2019 15:38, Kevin Wolf wrote:
>> Am 29.01.2019 um 13:04 hat Andrey Shinkevich geschrieben:
>
> diff --git a/block/qapi.c b/block/qapi.c
> index c66f949..0fde98c 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @
On 2019-01-29 13:51, Liam Merwick wrote:
> On 24/01/2019 10:53, Thomas Huth wrote:
>> It's either "GNU *Library* General Public version 2" or "GNU Lesser
>> General Public version *2.1*", but there was no "version 2.0" of the
>
> Should the word "License" be after both instances of "Public" above
Hi Philippe,
> I have been assigned to fix this issue, but rather fixing locally this
> BT device, fix the pattern on all devices.
> I'll post the series during the week and Cc you (and eventually the
> Debian LTS list when it gets merged). The series obsoletes this patch,
> so the plan is to not
On 29/01/2019 14:03, Thomas Huth wrote:
> On 2019-01-29 13:51, Liam Merwick wrote:
>> On 24/01/2019 10:53, Thomas Huth wrote:
>>> It's either "GNU *Library* General Public version 2" or "GNU Lesser
>>> General Public version *2.1*", but there was no "version 2.0" of the
>>
>> Should the word "Licen
Am 29.01.2019 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 29.01.2019 15:38, Kevin Wolf wrote:
> > Am 29.01.2019 um 13:04 hat Andrey Shinkevich geschrieben:
>
> diff --git a/block/qapi.c b/block/qapi.c
> index c66f949..0fde98c 100644
> --- a/block/qapi.c
> +++ b
v4:
Used KiB for MTP_WRITE_BUF_SZ (1/3)
Add back the Suggested-by tag (3/3)
v3:
Added patch 3/3
v2:
Rebased on top of master and retested
For larger files, not only do we keep reallocating to increase the mtp buffer
size, the write also happens in one go. This does two things:
Write to fi
This is a "pre-patch" to breaking up the write buffer for
MTP writes. Instead of allocating a mtp buffer equal to size
sent by the initiator, we start with a small size and reallocate
multiples (of that small size) as needed.
Signed-off-by: Bandan Das
---
hw/usb/dev-mtp.c | 27 +-
Eric Blake writes:
> On 1/28/19 8:24 AM, Bandan Das wrote:
>> This is a "pre-patch" to breaking up the write buffer for
>> MTP writes. Instead of allocating a mtp buffer equal to size
>> sent by the initiator, we start with a small size and reallocate
>> multiples (of that small size) as needed.
qemu_write_full takes care of partial blocking writes,
as in cases of larger file sizes
Suggested-by: Peter Maydell
Signed-off-by: Bandan Das
---
hw/usb/dev-mtp.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 1204a6
For every MTP_WRITE_BUF_SZ copied, this patch writes it to file before
getting the next block of data. The file is kept opened for the
duration of the operation but the sanity checks on the write operation
are performed only once when the write operation starts. Additionally,
we also update the fil
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 29 January 2019 12:25
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefan Hajnoczi ; Stefano
> Stabellini ; Kevin Wolf ; Max
> Reitz
> Subjec
Move channel i/o setup code out to a separate function. This decouples cio
setup from the virtio code path and allows us to make use of it for booting
dasd devices.
Signed-off-by: Jason J. Herne
Acked-by: Halil Pasic
Reviewed-by: Collin Walling
---
pc-bios/s390-ccw/main.c | 20 +---
Add verbose error output for when unexpected i/o errors happen. This eases the
burden of debugging and reporting i/o errors. No error information is printed
in the success case, here is an example of what is output on error:
vfio-ccw device I/O error - Interrupt Response Block Data:
Function C
Add bootindex property and iplb data for vfio-ccw devices. This allows us to
forward boot information into the bios for vfio-ccw devices.
Signed-off-by: Jason J. Herne
Acked-by: Halil Pasic
---
hw/s390x/ipl.c | 14 ++
hw/s390x/s390-ccw.c | 9 +
hw/vfio/
Create a new header for basic architecture specific definitions and add a
mapping of low core memory. This mapping will be used by the real dasd boot
process.
Signed-off-by: Jason J. Herne
---
pc-bios/s390-ccw/main.c | 2 +
pc-bios/s390-ccw/s390-arch.h | 100 ++
Create a separate library for channel i/o related code. This decouples
channel i/o operations from virtio and allows us to make use of them for
the real dasd boot path.
Signed-off-by: Jason J. Herne
---
pc-bios/s390-ccw/Makefile| 2 +-
pc-bios/s390-ccw/cio.c | 41 +
Allows guest to boot from a vfio configured real dasd device.
Signed-off-by: Jason J. Herne
---
docs/devel/s390-dasd-ipl.txt | 132 +++
pc-bios/s390-ccw/Makefile| 2 +-
pc-bios/s390-ccw/dasd-ipl.c | 249 +++
pc-bios/s390-ccw/dasd
Add struct for format-0 ccws. Support executing format-0 channel
programs and waiting for their completion before continuing execution.
This will be used for real dasd ipl.
Add cu_type() to channel io library. This will be used to query control
unit type which is used to determine if we are bootin
Now that we have a Channel I/O library let's modify virtio boot code to
make use of it for running channel programs.
Signed-off-by: Jason J. Herne
---
pc-bios/s390-ccw/virtio.c | 48 +++
1 file changed, 19 insertions(+), 29 deletions(-)
diff --git a/p
Make a new routine find_boot_device to locate the boot device for all
cases. not just virtio.
In one case no boot device is specified and a suitable boot device can not
be auto detected. The error message for this case was specific to virtio
devices. We update this message to remove virtio specifi
The boot method is different depending on which device type we are
booting from. Let's examine the control unit type to determine if we're
a virtio device. We'll eventually add a case to check for a real dasd device
here as well.
Signed-off-by: Jason J. Herne
---
pc-bios/s390-ccw/main.c | 15 +++
1 - 100 of 386 matches
Mail list logo
