On 12/07/18 17:51, Philippe Mathieu-Daudé wrote:
> All the consumers of "smbios_ipmi.h" are located in hw/smbios/.
I tried to verify this statement by grepping the tree for
"smbios_ipmi.h". There were zero hits. Please use the more precise
pathname "hw/smbios/ipmi.h". (I can't suggest just
On 12/10/2018 08:58 AM, Peter Maydell wrote:
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this.
Am 10.12.2018 um 14:38 hat Matthias Weckbecker geschrieben:
> Hi Kevin,
>
> I'm attaching a patch for qemu. Read below for details.
>
> There's a bug in qemu in the PCI bridge handling that can be triggered when
> following the steps below:
>
> 1) Create some VM (e.g. w/ virsh define)
> 2)
On 12/07/18 17:51, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/acpi-utils.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tests/acpi-utils.c b/tests/acpi-utils.c
> index 41dc1ea9b4..297af55d39 100644
> --- a/tests/acpi-utils.c
> +++
On 12/10/18 8:22 AM, Peter Maydell wrote:
> This section that clears VI/VF/VSE is new, and I'm not sure it's right.
> The spec says that the virtual IRQ interrupt is enabled only if {TGE,IMO}
> is {0,1}, but the meaning of the bit is "pending", and an interrupt
> can be pending without being
Le 12/10/18 à 3:39 PM, Peter Maydell a écrit :
On Mon, 10 Dec 2018 at 14:30, KONRAD Frederic
wrote:
Hi Peter,
Thanks for that patch!
I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
seem to be fixed by this patch. Is it supposed to fix the issue when we are
On Mon, Dec 10, 2018 at 03:06:59PM +0100, Alberto Garcia wrote:
> On Fri 07 Dec 2018 05:13:51 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> > @@ -148,12 +154,97 @@ int qcrypto_block_encrypt(QCryptoBlock *block,
> >
> > QCryptoCipher *qcrypto_block_get_cipher(QCryptoBlock *block)
> > {
> > -
On Thu, 6 Dec 2018 at 17:55, Richard Henderson
wrote:
>
> Provide a trivial implementation with zero limited ordering regions,
> which causes the LDLAR and STLLR instructions to devolve into the
> LDAR and STLR instructions from the base ARMv8.0 instruction set.
>
> Signed-off-by: Richard
On Thu, 6 Dec 2018 at 17:55, Richard Henderson
wrote:
>
> Since arm_hcr_el2_eff includes a check against
> arm_is_secure_below_el3, we can often remove a
> nearby check against secure state.
>
> In some cases, sort the call to arm_hcr_el2_eff
> to the end of a short-circuit logical sequence.
>
>
On Mon, 10 Dec 2018 at 14:30, KONRAD Frederic
wrote:
>
> Hi Peter,
>
> Thanks for that patch!
>
> I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
> seem to be fixed by this patch. Is it supposed to fix the issue when we are
> doing a reset_request through a MMIO
Hi,
Hope this is the right place for this question.
I was wondering whether the TCG i386 backend is currently able to generate SIMD
code ( vector loads/store, moves, vector arithmetic, etc ).
Looking around on patchwork I found these patches:
On Tue, Nov 20, 2018 at 09:10:23PM -0800, Li Qiang wrote:
> And also do some code cleanup.
> A lot of thanks to Markus's review and advice.
>
> v2: fix some small issue per Markus's review.
>
> Li Qiang (3):
> fw_cfg: fix -boot bootsplash error checking
> fw_cfg: fix -boot reboot-timeout
On Thu, Nov 22, 2018 at 05:03:09PM +, Peter Maydell wrote:
> The qemu_create_display_surface_guestmem() function was added in
> commit a77549b3ffcc24c32ee4e but apparently never used. Remove it.
>
> (The API of this function is in any case awkward as a generic
> function: it assumes that a
Hi Peter,
Thanks for that patch!
I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
seem to be fixed by this patch. Is it supposed to fix the issue when we are
doing a reset_request through a MMIO device?
It happens (rarely) with this kind of guest code:
exit:
On Mon, Nov 26, 2018 at 04:42:40PM +0400, Marc-André Lureau wrote:
> As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
> review, let's define a common set of backend conventions to help with
> management layer implementation, and interoperability.
>
> Signed-off-by: Marc-André
On Mon, Nov 26, 2018 at 04:42:49PM +0400, Marc-André Lureau wrote:
> Add a new virtio-input device, which connects to a vhost-user
> backend. Usage:
>
> -object vhost-user-backend,id=vuid,chardev=... \
> -device vhost-user-input-pci,vhost-user=vuid
>
> vhost-user-input is similar to
On Mon, Nov 26, 2018 at 04:42:46PM +0400, Marc-André Lureau wrote:
> Ask vhost user input backend the list of virtio_input_config.
Reviewed-by: Gerd Hoffmann
>
> Signed-off-by: Marc-André Lureau
> ---
> contrib/libvhost-user/libvhost-user.h | 1 +
> include/hw/virtio/vhost-backend.h |
On Mon, 10 Dec 2018 at 14:13, Cornelia Huck wrote:
>
> On Mon, 10 Dec 2018 13:58:03 +
> Peter Maydell wrote:
>
> > Taking the address of a field in a packed struct is a bad idea, because
> > it might not be actually aligned enough for that pointer type (and
> > thus cause a crash on
On Thu, 6 Dec 2018 at 17:55, Richard Henderson
wrote:
>
> Replace arm_hcr_el2_{fmo,imo,amo} with a more general routine
> that also takes SCR_EL3.NS (aka arm_is_secure_below_el3) into
> account, as documented for the plethora of bits in HCR_EL2.
>
> Signed-off-by: Richard Henderson
>
> v3:
On Mon, 10 Dec 2018 13:58:03 +
Peter Maydell wrote:
> Taking the address of a field in a packed struct is a bad idea, because
> it might not be actually aligned enough for that pointer type (and
> thus cause a crash on dereference on some host architectures). Newer
> versions of clang warn
There is no reason to allocate mouse events using malloc, we can
allcoate them from stack instead, save a few cpu cycles and make the
code more readable with c99 initializers.
Suggested-by: FelixYao
Signed-off-by: Gerd Hoffmann
---
include/ui/input.h | 3 ---
ui/input.c | 68
On Fri 07 Dec 2018 05:13:51 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> @@ -148,12 +154,97 @@ int qcrypto_block_encrypt(QCryptoBlock *block,
>
> QCryptoCipher *qcrypto_block_get_cipher(QCryptoBlock *block)
> {
> -return block->cipher;
> +/* Ciphers should be accessed through pop/push
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this.
Avoid the problem by using local copies of the PMCW
On Mon, 10 Dec 2018 at 13:32, Dr. David Alan Gilbert
wrote:
> Is the problem here that the field could actually be misaligned (on
> any conceivable build) or is it just a matter of convincing clang it's
> safe?
This is mostly a "clang doesn't know that the struct field
will actually always be 4
Hi Maran,
On Wed, Dec 5, 2018 at 7:04 PM Maran Wilson wrote:
>
> On 12/5/2018 5:20 AM, Stefan Hajnoczi wrote:
> > On Tue, Dec 04, 2018 at 02:44:33PM -0800, Maran Wilson wrote:
> >> On 12/3/2018 8:35 AM, Stefano Garzarella wrote:
> >>> On Mon, Dec 3, 2018 at 4:44 PM Rob Bradford
> >>> wrote:
>
On Mon, 10 Dec 2018 14:06:42 +0100
Halil Pasic wrote:
> On Mon, 10 Dec 2018 12:04:36 +
> Peter Maydell wrote:
>
> > Taking the address of a field in a packed struct is a bad idea, because
> > it might not be actually aligned enough for that pointer type (and
> > thus cause a crash on
On Dec 9, 2018 5:00 PM, "BALATON Zoltan" wrote:
>
> Hello,
>
> I was searching for some good summary on how to implement new devices and
machines in QEMU for those who might want to start working on it but not
much seems to be available. I've found this which seems to be useful:
>
>
On Fri, Nov 30, 2018 at 02:47:00PM +0800, linzhecheng wrote:
> we should perform these things as same as usb_host_close.
>
> Signed-off-by: linzhecheng
>
> diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> index b6602ded4e..2016375e6b 100644
> --- a/hw/usb/host-libusb.c
> +++
On Mon 10 Dec 2018 02:21:56 PM CET, Daniel P. Berrangé wrote:
> On Mon, Dec 10, 2018 at 11:44:22AM +0100, Alberto Garcia wrote:
>> On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
>> > Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
>>
>> You forgot
On Wed, Nov 28, 2018 at 07:59:32PM +0400, Marc-André Lureau wrote:
> Looking at chardev/spice.c code, I realize compilation was broken for
> a while with spice-server < 0.12.3. Let's bump required version
> to 0.12.5, released May 19 2014, instead of adding more #ifdef.
>
> (this patch combines
Marc-André Lureau writes:
> Hi
>
> On Mon, Dec 10, 2018 at 1:52 PM Markus Armbruster wrote:
>>
>> Marc-André Lureau writes:
>>
>> > Now that the schema can be configured, it is crucial that all types
>> > are configured the same. Make sure config-host.h is included, by
>> > checking osdep.h
On Thu, Nov 29, 2018 at 12:50:48PM +0100, Thomas Huth wrote:
> There are some "#ifdef CONFIG_VIRTIO_VGA" in the code here which
> do not work as expected: CONFIG_VIRTIO_VGA is a Makefile switch,
> but not a CPP macro, so the "guarded" code currently simply never
> gets enabled.
>
> So enable this
* Cornelia Huck (coh...@redhat.com) wrote:
> On Mon, 10 Dec 2018 12:27:56 +
> Peter Maydell wrote:
>
> > On Thu, 27 Sep 2018 at 09:25, Thomas Huth wrote:
> > >
> > > struct SubchDev embeds several other structures which are marked with
> > > QEMU_PACKED. This causes the compiler to not care
On Mon, Dec 10, 2018 at 11:44:22AM +0100, Alberto Garcia wrote:
> On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> > Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
>
> You forgot to update the new function names in the commit message.
>
> > -int
On Fri, Nov 30, 2018 at 05:38:50PM +0800, Mao Zhongyi wrote:
> Use DeviceClass rather than SysBusDeviceClass in
> tusb6010_class_init().
>
> Cc: kra...@redhat.com
>
> Signed-off-by: Mao Zhongyi
> Signed-off-by: Zhang Shengju
Reviewed-by: Gerd Hoffmann
> ---
> hw/usb/tusb6010.c | 8 +++-
On Fri, Nov 30, 2018 at 05:38:36PM +0800, Mao Zhongyi wrote:
> Use DeviceClass rather than SysBusDeviceClass in
> g364fb_sysbus_class_init().
>
> Cc: pbonz...@redhat.com
> Cc: kra...@redhat.com
> Cc: f4...@amsat.org
> Cc: alistair.fran...@wdc.com
>
> Signed-off-by: Mao Zhongyi
> Signed-off-by:
On Fri, Nov 30, 2018 at 10:45:12PM +0100, Paolo Bonzini wrote:
> This function is only needed when Q35 is in use. Moving it to
> the same file that uses it lets you disable the entire USB
> subsystem in x86_64-softmmu.mak; of course doing that will
> cause -usb to break horribly, but one thing at
On Mon, 10 Dec 2018 12:27:56 +
Peter Maydell wrote:
> On Thu, 27 Sep 2018 at 09:25, Thomas Huth wrote:
> >
> > struct SubchDev embeds several other structures which are marked with
> > QEMU_PACKED. This causes the compiler to not care for proper alignment
> > of these structures. When we
On Thu, Dec 06, 2018 at 02:39:23PM +0100, Juergen Gross wrote:
> Don't call xen_be_set_max_grant_refs() in usbback_alloc(), as the
> gnttabdev pointer won't be initialised yet. The call can easily be
> moved to usbback_connect().
Added to usb queue.
thanks,
Gerd
Please don't use "Content-Transfer-Encoding: base64".
Andrey Shinkevich writes:
> On 07.12.2018 19:20, Eric Blake wrote:
>
>> On 12/7/18 4:00 AM, Andrey Shinkevich wrote:
[...]
>>> +++ b/block/qcow2.c
>>> @@ -4270,6 +4270,12 @@ static ImageInfoSpecific
>>>
On Mon, 10 Dec 2018 at 12:15, Alex Bennée wrote:
> Peter Maydell writes:
> > though I might actually have meant pause_all_vcpus().
> > (For pause_all_vcpus() I think the correct thing is to
> > fix the hw/i386/kvmvapic.c code to work in some other way,
> > and then assert that pause_all_vcpus()
On Mon, 10 Dec 2018 12:04:36 +
Peter Maydell wrote:
> Taking the address of a field in a packed struct is a bad idea, because
> it might not be actually aligned enough for that pointer type (and
> thus cause a crash on dereference on some host architectures). Newer
> versions of clang warn
On Dec 7, 2018 9:59 AM, "Mark Cave-Ayland"
wrote:
>
> This patchset is an attempt at trying to improve the VMX (Altivec)
instruction
> performance by making use of the new TCG vector operations where possible.
>
Hello, Mark.
I just want to say that I support these efforts. Very interesting, it
On Mon, Dec 10, 2018 at 12:11:09PM +, Leonardo Soares Müller wrote:
> Hi, I did not save that Mageia 7 data as I was unaware I could do this.
> The data below is from another crash with openSUSE Leap, this time I
> saved this backtrace with generate-core-file.
> On #4 it shows:
> $2 = {pid =
David Gibson writes:
>> >> +if (arch_info->address == trace_handler_addr) {
>> >> +cpu_synchronize_state(cs);
>> >> +kvm_remove_breakpoint(cs, trace_handler_addr, 4,
>> >> GDB_BREAKPOINT_SW);
>> >> +
>> >> +cpu_memory_rw_debug(cs, env->spr[SPR_SRR0] - 4, (uint8_t *),
On 12/10/18 1:04 PM, Peter Maydell wrote:
> Taking the address of a field in a packed struct is a bad idea, because
> it might not be actually aligned enough for that pointer type (and
> thus cause a crash on dereference on some host architectures). Newer
> versions of clang warn about this. Avoid
On 12/10/18 12:46 PM, Peter Maydell wrote:
> clang complains about taking the address of a packed
> member of a struct:
>
> target/i386/kvm.c:1245:27: warning: taking address of packed member 'cpuid'
> of class or structure '' may result in an unaligned pointer value
>
Am 10.12.2018 um 13:14 hat Denis Plotnikov geschrieben:
> >> @@ -491,9 +506,17 @@ int64_t aio_compute_timeout(AioContext *ctx);
> >>*/
> >> static inline void aio_disable_external(AioContext *ctx)
> >> {
> >> +aio_context_acquire(ctx);
> >> atomic_inc(>external_disable_cnt);
> >>
Hi, I did not save that Mageia 7 data as I was unaware I could do this.
The data below is from another crash with openSUSE Leap, this time I
saved this backtrace with generate-core-file.
QEMU command line:
env QEMU_AUDIO_ADC_VOICES=0 QEMU_AUDIO_DRV=pa \
QEMU_AUDIO_DAC_FIXED_FREQ=96000 \
On 07.12.2018 15:26, Kevin Wolf wrote:
> Am 05.12.2018 um 13:23 hat Denis Plotnikov geschrieben:
>> At the time, the "drained section" doesn't protect Block Driver State
>> from the requests appearing in the vCPU threads.
>> This could lead to the data loss because of request coming to
>> an
On Thu, 27 Sep 2018 at 09:25, Thomas Huth wrote:
>
> struct SubchDev embeds several other structures which are marked with
> QEMU_PACKED. This causes the compiler to not care for proper alignment
> of these structures. When we later pass around pointers to the unaligned
> struct members during
On 07.12.2018 19:20, Eric Blake wrote:
> On 12/7/18 4:00 AM, Andrey Shinkevich wrote:
>> 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:
Peter Maydell writes:
> On Mon, 10 Dec 2018 at 11:06, Alex Bennée wrote:
>>
>>
>> Peter Maydell writes:
>> > We discussed this a little while back:
>> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg00154.html
>> > and Jaap reported a bug which I suspect of being the same thing:
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by not using the
"modify in place" byte
clang complains about taking the address of a packed
member of a struct:
target/i386/kvm.c:1245:27: warning: taking address of packed member 'cpuid' of
class or structure '' may result in an unaligned pointer value
[-Waddress-of-packed-member]
c = cpuid_find_entry(_data.cpuid, 1, 0);
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> $ qemu-system-x86_64 -S -monitor stdio
> (qemu) info fw_cfg
> TypePermSizeSpecific Order Info
>signature RO 4 QEMU
> id RO 4 0x0003
>
On Mon, Dec 10, 2018 at 3:27 PM Peter Maydell wrote:
>
> Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
> be byte-swapped. This means it can't be used when the UUID
> to be swapped is in a packed member of a struct. It's also
> out of line with the general bswap*() functions we
> From: Emilio G. Cota [mailto:c...@braap.org]
> +/*
> + * A dynamic callback has an insertion point that is determined at run-time.
> + * Usually the insertion point is somewhere in the code cache; think for
> + * instance of a callback to be called upon the execution of a particular TB.
> + */
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by generating the
UUID into a local
Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
be byte-swapped. This means it can't be used when the UUID
to be swapped is in a packed member of a struct. It's also
out of line with the general bswap*() functions we provide
in bswap.h, which take the value to be swapped and return
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this.
Instead of passing UUID related functions the address
This patchset fixes the remaining clang warnings in the block/ code
about taking the address of a packed struct member, which are all
in block/vpc and block/vdi code handling UUIDs. Mostly I fix
these by copying the unaligned field to/from a local variable.
In the case of qemu_uuid_bswap() I opted
On Mon, 10 Dec 2018 at 11:06, Alex Bennée wrote:
>
>
> Peter Maydell writes:
> > We discussed this a little while back:
> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg00154.html
> > and Jaap reported a bug which I suspect of being the same thing:
> >
On Mon, Dec 10, 2018 at 2:11 PM Markus Armbruster wrote:
>
> Markus Armbruster writes:
>
> > Marc-André Lureau writes:
> >
> >> Hi
> >> On Thu, Dec 6, 2018 at 9:42 PM Markus Armbruster wrote:
> >>>
> >>> Marc-André Lureau writes:
> >>>
> >>> > Wrap generated enum/struct members and code with
Hi
On Mon, Dec 10, 2018 at 12:51 PM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > On Wed, Dec 5, 2018 at 10:41 PM Markus Armbruster wrote:
> >>
> >> Marc-André Lureau writes:
> >>
> >> > This makes it a bit clearer what is the intent of the dictionnary for
> >>
> >> dictionary
>
Hi
On Mon, Dec 10, 2018 at 1:52 PM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > Now that the schema can be configured, it is crucial that all types
> > are configured the same. Make sure config-host.h is included, by
> > checking osdep.h inclusion. The build-sys tracks the
On 12/10/18 12:09 PM, Peter Maydell wrote:
> On Mon, 10 Dec 2018 at 11:00, Philippe Mathieu-Daudé
> wrote:
>>
>> Hi Jason,
>>
>> On 12/7/18 5:42 AM, Jason A. Donenfeld wrote:
>>> On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell
>>> wrote:
It's still stuck, because unconditionally adding a
On Mon, Dec 10, 2018 at 2:03 PM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > Report the set of missing or unknown keys. And give a hint about the
> > accepted keys.
>
> Suggest to add:
>
> The error message for multiple meta type members (visible in
>
On Mon, 10 Dec 2018 at 11:00, Philippe Mathieu-Daudé wrote:
>
> Hi Jason,
>
> On 12/7/18 5:42 AM, Jason A. Donenfeld wrote:
> > On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell
> > wrote:
> >> It's still stuck, because unconditionally adding a second serial
> >> port to the virt board breaks some
Peter Maydell writes:
> We use cpu_stop_current() to ensure the current CPU has stopped
> from places like qemu_system_reset_request(). Unfortunately its
> current implementation has a race. It calls qemu_cpu_stop(),
> which sets cpu->stopped to true even though the CPU hasn't
> actually
Hi Jason,
On 12/7/18 5:42 AM, Jason A. Donenfeld wrote:
> On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell
> wrote:
>> It's still stuck, because unconditionally adding a second serial
>> port to the virt board breaks some commonly used existing guest
>> code (UEFI + Linux), and it's not clear to
Error I see in terminal:
AMD CPU doesn't support hyperthreading. Please configure -smp options properly.
Error I see in my windows 10 vm:
SYSTEM THREAD EXCEPTION NOT HANDLED
I am unable to use Qemu at all. Serious problem.
CPU: AMD Ryzen 5 1600X Six-Core Processor × 6
--
You received this bug
On Fri 07 Dec 2018 05:13:50 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> Introduce QCryptoBlock-based functions and use them where possible.
> This is needed to implement thread-safe encrypt/decrypt operations.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Daniel P. Berrangé
On Fri 07 Dec 2018 05:13:49 PM CET, Vladimir Sementsov-Ogievskiy wrote:
> Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
You forgot to update the new function names in the commit message.
> -int qcrypto_block_decrypt_helper(QCryptoCipher *cipher,
> -int
On 2018/12/6 23:14, Peter Maydell wrote:
> At the moment the Arm implementations of kvm_arch_{get,put}_registers()
> don't support having QEMU change the values of system registers
> (aka coprocessor registers for AArch32). This is because although
> kvm_arch_get_registers() calls
Markus Armbruster writes:
> Marc-André Lureau writes:
>
>> Hi
>> On Thu, Dec 6, 2018 at 9:42 PM Markus Armbruster wrote:
>>>
>>> Marc-André Lureau writes:
>>>
>>> > Wrap generated enum/struct members and code with #if/#endif, using the
>>>
>>> enum and struct members
>>
>> ok
>>
>>>
>>> >
Marc-André Lureau writes:
> Report the set of missing or unknown keys. And give a hint about the
> accepted keys.
Suggest to add:
The error message for multiple meta type members (visible in
tests/qapi-schema/double-type.err) is not improved.
> Signed-off-by: Marc-André Lureau
Marc-André Lureau writes:
> Introduce a new helper function to check if the given keys are known,
> and if mandatory keys are present. The function will be reused in
> other places in the following code changes.
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Marc-André Lureau writes:
> Now that the schema can be configured, it is crucial that all types
> are configured the same. Make sure config-host.h is included, by
> checking osdep.h inclusion. The build-sys tracks the dependency and
> rebuilds the types if the configuration changed.
>
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:58
> To: Paul Durrant
> Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 07 December 2018 15:26
> To: Paul Durrant
> Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v2
On 2018/12/6 下午9:59, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 09:57:22PM +0800, Jason Wang wrote:
On 2018/12/6 下午2:35,elohi...@gmail.com wrote:
From: Xie Yongji
This patchset is aimed at supporting qemu to reconnect
vhost-user-blk backend after vhost-user-blk backend crash or
On Mon, 10 Dec 2018 17:20:43 +1100
David Gibson wrote:
> On Mon, Nov 12, 2018 at 03:12:26PM +1100, Alexey Kardashevskiy wrote:
> >
> >
> > On 12/11/2018 05:10, Greg Kurz wrote:
> > > Hi Alexey,
> > >
> > > Just a few remarks. See below.
> > >
> > > On Thu, 8 Nov 2018 12:44:06 +1100
> > >
On 12/7/18 11:48 PM, no-re...@patchew.org wrote:
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker installed, you can probably reproduce
> it
> locally.
>
...
> The full log is available at
>
On 12/7/18 6:54 PM, Michael S. Tsirkin wrote:
> On Fri, Dec 07, 2018 at 06:03:59PM +0100, Philippe Mathieu-Daudé wrote:
>> $ qemu-system-x86_64 -S -monitor stdio
>> (qemu) info fw_cfg
>> TypePermSizeSpecific Order Info
>
> Can we do better than "Info"?
For some entry this
Hi Michael, Peter.
On 12/7/18 6:57 PM, Michael S. Tsirkin wrote:
> On Fri, Dec 07, 2018 at 06:03:56PM +0100, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> hw/arm/virt-acpi-build.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git
I've just opened #1807675 for the new bug.
Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1803160
Title:
qemu-3.1.0-rc0: tcg.c crash in temp_load
Status in QEMU:
Fix Committed
Bug
Public bug reported:
As discussed in #1803160 I'm opening a new ticket for the new bug.
QEMU version:
-
qemu from git, master branch commit
80422b00196a7af4c6efb628fae0ad8b644e98af
Summary:
TCG crashes in i386 and x86_64 when it tries to execute some specific
illegal
Hi Seth,
On 12/10/18 4:39 AM, Seth K wrote:
> Thank you all for help with my last patch. I found one more entry in my
> notes that could be a bug, or could be a misunderstanding on my part.
>
> The memory map in DocID15818 (Rev 15) datasheet says:
> ADC1 - ADC2 - ADC3: 0x40012000-0x400123FF
Marc-André Lureau writes:
> On Wed, Dec 5, 2018 at 10:41 PM Markus Armbruster wrote:
>>
>> Marc-André Lureau writes:
>>
>> > This makes it a bit clearer what is the intent of the dictionnary for
>>
>> dictionary
>
> sigh, this must be a very common misspell (dictionnaire in french)
Muscle
201 - 290 of 290 matches
Mail list logo
