PING
On Mon, Aug 19, 2019 at 4:22 PM Bishara AbuHattoum
wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1733165
>
> Uppon renaming a NIC to a Chinese name and invoking the network get
> interfaces command, guest-network-get-interfaces, the returned name
> field has the (\ufffd) value for ea
On Wed, 21 Aug 2019 10:25:45 +0200
Laurent Vivier wrote:
> This is the patch originally sent by Justin, modified
> to change the parameter size on FreeBSD only.
>
> Justin, could you review and test on FreeBSD?
> Peter, could you run "make check" on your MacOS X host?
>
> Thanks,
> Laurent
>
>
On Wed, 21 Aug 2019 10:25:45 +0200
Laurent Vivier wrote:
> This is the patch originally sent by Justin, modified
> to change the parameter size on FreeBSD only.
>
> Justin, could you review and test on FreeBSD?
> Peter, could you run "make check" on your MacOS X host?
>
> Thanks,
> Laurent
>
>
I only attempt to fix this bug for powerpc at the moment.
For x86_64... there is no existing attempt to handle fp
exceptions at all. It will be quite the job to fix.
r~
Richard Henderson (1):
target/ppc: Fix do_float_check_status vs inexact
target/ppc/fpu_helper.c | 10 +++---
1 file
See the cross-post cover letter for details:
https://www.redhat.com/archives/libguestfs/2019-August/msg00322.html
Eric Blake (1):
protocol: Add NBD_CMD_FLAG_FAST_ZERO
doc/proto.md | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
--
2.21
This is the patch originally sent by Justin, modified
to change the parameter size on FreeBSD only.
Justin, could you review and test on FreeBSD?
Peter, could you run "make check" on your MacOS X host?
Thanks,
Laurent
Justin Hibbits (1):
Fix cacheline detection on FreeBSD/powerpc.
util/cache
https://bugzilla.redhat.com/show_bug.cgi?id=1733165
Uppon renaming a NIC to a Chinese name and invoking the network get
interfaces command, guest-network-get-interfaces, the returned name
field has the (\ufffd) value for each Chinese character the NIC name
had, this value is the indication that th
On Mon, 12 Aug 2019 at 16:48, Alex Williamson
wrote:
>
> On Mon, 12 Aug 2019 16:38:05 +0100
> Peter Maydell wrote:
>
> > On Mon, 12 Aug 2019 at 16:35, Alex Williamson
> > wrote:
> > > Quoting new commit log:
> > >
> > > This makes sure the pci config space allocation is big enough,
> > >
On Mon, 12 Aug 2019 16:38:05 +0100
Peter Maydell wrote:
> On Mon, 12 Aug 2019 at 16:35, Alex Williamson
> wrote:
> > Quoting new commit log:
> >
> > This makes sure the pci config space allocation is big enough,
> > so accessing the PCIe extended config space doesn't overflow
> >
On Mon, 12 Aug 2019 at 16:35, Alex Williamson
wrote:
> Quoting new commit log:
>
> This makes sure the pci config space allocation is big enough,
> so accessing the PCIe extended config space doesn't overflow
> the pci config space buffer.
>
> PCI(e) config space is
On Mon, 12 Aug 2019 14:39:53 +0100
Peter Maydell wrote:
> On Mon, 12 Aug 2019 at 13:51, Philippe Mathieu-Daudé
> wrote:
> >
> > On 8/12/19 2:45 PM, Paolo Bonzini wrote:
> > > On 12/08/19 08:52, Gerd Hoffmann wrote:
> > >> Just found while investigating
> > >> https://bugzilla.redhat.com/s
On 8/12/19 3:39 PM, Peter Maydell wrote:
> On Mon, 12 Aug 2019 at 13:51, Philippe Mathieu-Daudé
> wrote:
>>
>> On 8/12/19 2:45 PM, Paolo Bonzini wrote:
>>> On 12/08/19 08:52, Gerd Hoffmann wrote:
Just found while investigating
https://bugzilla.redhat.com/show_bug.cgi?id=1707118
>
On Mon, 12 Aug 2019 at 13:51, Philippe Mathieu-Daudé wrote:
>
> On 8/12/19 2:45 PM, Paolo Bonzini wrote:
> > On 12/08/19 08:52, Gerd Hoffmann wrote:
> >> Just found while investigating
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1707118
> >>
> >> Found PCIe extended config space filled with
On 8/12/19 2:45 PM, Paolo Bonzini wrote:
> On 12/08/19 08:52, Gerd Hoffmann wrote:
>> Just found while investigating
>> https://bugzilla.redhat.com/show_bug.cgi?id=1707118
>>
>> Found PCIe extended config space filled with random crap due to
>> allocation being too small (conventional pci config
On 12/08/19 08:52, Gerd Hoffmann wrote:
> Just found while investigating
> https://bugzilla.redhat.com/show_bug.cgi?id=1707118
>
> Found PCIe extended config space filled with random crap due to
> allocation being too small (conventional pci config space only).
>
> PCI(e) config space is guest
Just found while investigating
https://bugzilla.redhat.com/show_bug.cgi?id=1707118
Found PCIe extended config space filled with random crap due to
allocation being too small (conventional pci config space only).
PCI(e) config space is guest writable. Writes are limited by
write mask (which pro
From: Olivier Dion
When the emulated process try to execve itself through /proc/self/exe,
QEMU user will be executed instead of the process.
The following short program demonstrated that:
--
#include
#include
#include
stati
I have problem in xen with qemu xhci with usbredir backend.
Windows bluetooth (BCM20703) driver does not work without proposed patch.
Interrupt EP does not work as expected and described in USB spec.
usb_20.pdf/5.7.3 Interrupt Transfer Packet Size Constraint:
An endpoint must always transmit
I have problem in xen with qemu xhci with usbredir backend.
Windows bluetooth (BCM20703) driver does not work without proposed patch.
Interrupt EP does not work as expected and described in USB spec.
usb_20.pdf/5.7.3 Interrupt Transfer Packet Size Constraint:
An endpoint must always transmit
On Tue, Jul 16, 2019 at 03:38:00AM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> patch tries
While fuzzing the virtio-net tx vq, I ran into an assertion failure due
to iov_copy offsets larger than the total iov size. Though there is
a check to cover this, it does not execute when !n->has_vnet_hdr. This
patch tries to fix this.
The call stack for the assertion failure:
#8 in __assert_fai
On Sun, 2019-06-30 at 18:08 +0300, Maxim Levitsky wrote:
> It looks like Linux block devices, even in O_DIRECT mode don't have any user
> visible
> limit on transfer size / number of segments, which underlying block device
> can have.
> The block layer takes care of enforcing these limits by spli
It looks like Linux block devices, even in O_DIRECT mode don't have any user
visible
limit on transfer size / number of segments, which underlying block device can
have.
The block layer takes care of enforcing these limits by splitting the bios.
By limiting the transfer sizes, we force qemu to
The following changes since commit a050901d4b40092dc356b59912c6df39e389c7b9:
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190612' into
staging (2019-06-12 14:43:47 +0100)
are available in the Git repository at:
https://github.com/rth7680/qemu.git tags/pull-tcg-20190612
The AccelClass::opt_name is not used. Unless there is a reason
for keeping hat attribute, this patch remove it.
Git: https://github.com/wainersm/qemu
Branch: accel_del_opt_name
Travis: https://travis-ci.org/wainersm/qemu/builds/539721285
(Failed test case is not related with this change as well as
On this series I changed the semantics of -accel help so that
it shows only the accelerators enabled in the QEMU target
binary. This behavior is now alike -cpu and -machine helps.
Another reason for this proposal is that I am working on
an improvement of Avocado QEMU framework which should skip
te
I suggest to remove the pre_save handler that saves the timebase before
migrate. The commit that added this was ported from x86:
6053a86fe7bd: kvmclock: reduce kvmclock difference on migration
The review [1] had a discussion about it. The author says that a VM
already paused 10 minutes ago shoul
The parallel NOR flash models don't have a specific maintainer and
default to the 'Block layer core' section.
Step in to maintain them.
The section still get covered by the Block layer team, but the idea
is to offload them.
The two devices are very similar (same technology), the difference
is most
Patchew URL:
https://patchew.org/QEMU/20190417053225.27505-1-richard.hender...@linaro.org/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
Patchew URL:
https://patchew.org/QEMU/20190417053225.27505-1-richard.hender...@linaro.org/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin
This is a third variant attempting to fix the problem of
the -L interp_prefix handling not coping well pointing to
a full chroot.
Previous versions include:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06592.html
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg07304.html
Both
On 26/03/19 08:14, IOMMU AUTHOR wrote:
> got some clarification regarding this.
>
> i no longer wish to get this patch merged.
Thanks very much for your understanding.
Paolo
On Wed, Mar 20, 2019 at 4:18 PM IOMMU AUTHOR wrote:
>
>
> On Wed, Mar 20, 2019 at 12:16 AM IOMMU AUTHOR
> wrote:
>
>> i'd rather the copyright notice on these files looks like i've put it
>> below and since i just simply snipped my name(i'll provide legal proof
>> that this is my name, if requir
On Wed, Mar 20, 2019 at 12:16 AM IOMMU AUTHOR
wrote:
> i'd rather the copyright notice on these files looks like i've put it
> below and since i just simply snipped my name(i'll provide legal proof
> that this is my name, if required), i don't expect this to be an issue.
>
is this getting queued
i'd rather the copyright notice on these files looks like i've put it
below and since i just simply snipped my name(i'll provide legal proof
that this is my name, if required), i don't expect this to be an issue.
IOMMU AUTHOR (1):
update copyright notice
hw/i386/amd_iommu.c | 1 -
hw/i386/amd_
ping - soft freeze is less than a week away & I would like to see this
in a chardev pull request in time for 4.0
On Wed, Feb 27, 2019 at 01:55:22PM +, Daniel P. Berrangé wrote:
> This series provides the chardev part of the authorization control series
> previously posted as:
>
> v1: https:
ping - soft freeze is less than a week away & I'd like to see this
merged for this release.
On Wed, Feb 27, 2019 at 02:53:23PM +, Daniel P. Berrangé wrote:
> This series provides the migration part of the authorization control series
> previously posted as:
>
> v1: https://lists.gnu.org/arc
i think it is best put as i've updated.
David Kiarie (1):
update copyright notice
hw/i386/amd_iommu.c | 2 +-
hw/i386/amd_iommu.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.21.0
Patchew URL:
https://patchew.org/QEMU/20190221155359.8247-1-davidkiar...@gmail.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190221155359.8247-1-davidkiar...@gmail.com
Subject: [Qemu-devel] [PATCH 0/1] snip my name and
This series provides the migration part of the authorization control series
previously posted as:
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg04482.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg05727.html
v3: https://lists.gnu.org/archive/html/qemu-devel/
This series provides the chardev part of the authorization control series
previously posted as:
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg04482.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg05727.html
v3: https://lists.gnu.org/archive/html/qemu-devel/20
update copyright notice to reflect my full legal name. looks better to
me that way.
also, that way people are not under the impression i *own* qemu AMD
IOMMU.
thanks.
David Kiarie (1):
hw/i386: update copyright notice
hw/i386/amd_iommu.c | 2 +-
hw/i386/amd_iommu.h | 2 +-
2 files changed, 2
On Thu, Feb 21, 2019 at 7:09 PM Jan Kiszka wrote:
> On 21.02.19 17:05, Eric Blake wrote:
> > On 2/21/19 9:53 AM, David Kiarie wrote:
> >> the occurrence of my name and email on the files below may have led to
> >> some confusion in the reporting of a few recent bugs.
> >>
> >> i have therefore ch
On Thu, Feb 21, 2019 at 8:04 PM David Kiarie wrote:
> i personally mostly don't care what someone does with the code i wrote
> but i mostly had this since everyone else was doing it but the presence
> of the email on the file led to some recent confusion and i will
> therefore drop it.
>
i think
On Thu, Feb 21, 2019 at 8:35 PM Philippe Mathieu-Daudé
wrote:
> On 2/21/19 6:13 PM, Markus Armbruster wrote:
>
> >
> > Can we resync with the kernel's script to get this feature? Or should
> > we cherry-pick it?
>
> I think we are out-of-sync and only cherry-picking.
>
you can do this if you so
On 2/21/19 6:13 PM, Markus Armbruster wrote:
> Jan Kiszka writes:
>
>> On 21.02.19 17:48, Markus Armbruster wrote:
>>> Jan Kiszka writes:
>>>
On 21.02.19 17:05, Eric Blake wrote:
> On 2/21/19 9:53 AM, David Kiarie wrote:
>> the occurrence of my name and email on the files below may
Jan Kiszka writes:
> On 21.02.19 17:48, Markus Armbruster wrote:
>> Jan Kiszka writes:
>>
>>> On 21.02.19 17:05, Eric Blake wrote:
On 2/21/19 9:53 AM, David Kiarie wrote:
> the occurrence of my name and email on the files below may have led to
> some confusion in the reporting of a
i personally mostly don't care what someone does with the code i wrote
but i mostly had this since everyone else was doing it but the presence
of the email on the file led to some recent confusion and i will
therefore drop it.
thanks.
David Kiarie (1):
hw/i386: drop my email from copyright decl
i will just drop the email.
thanks.
On 21.02.19 17:48, Markus Armbruster wrote:
Jan Kiszka writes:
On 21.02.19 17:05, Eric Blake wrote:
On 2/21/19 9:53 AM, David Kiarie wrote:
the occurrence of my name and email on the files below may have led to
some confusion in the reporting of a few recent bugs.
i have therefore choosen t
Jan Kiszka writes:
> On 21.02.19 17:05, Eric Blake wrote:
>> On 2/21/19 9:53 AM, David Kiarie wrote:
>>> the occurrence of my name and email on the files below may have led to
>>> some confusion in the reporting of a few recent bugs.
>>>
>>> i have therefore choosen to snip it.
>>
>> Dropping an
On 21.02.19 17:05, Eric Blake wrote:
On 2/21/19 9:53 AM, David Kiarie wrote:
the occurrence of my name and email on the files below may have led to
some confusion in the reporting of a few recent bugs.
i have therefore choosen to snip it.
Dropping an email from the copyright line makes sense;
On 2/21/19 9:53 AM, David Kiarie wrote:
> the occurrence of my name and email on the files below may have led to
> some confusion in the reporting of a few recent bugs.
>
> i have therefore choosen to snip it.
Dropping an email from the copyright line makes sense; dropping the
Copyright declarati
the occurrence of my name and email on the files below may have led to
some confusion in the reporting of a few recent bugs.
i have therefore choosen to snip it.
David Kiarie (1):
hw/i386: snip my name and email
hw/i386/amd_iommu.c | 1 -
hw/i386/amd_iommu.h | 1 -
2 files changed, 2 deletion
The amount of Python code that is being reused by a now large number
of different scripts and tests on QEMU urges for a better structure.
This addresses the feedback received on a previous RFC[1], but further
changes that will really benefit from this change were not attempted
here. Once, the mod
Patchew URL:
https://patchew.org/QEMU/20190122150543.16889-1-bal...@linux.vnet.ibm.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEG
On Wed, 30 Jan 2019 at 20:22, Mathew Maidment wrote:
> This is a patch that fixes a condition within disas_uncond_b_reg() related to
> BRAA and BLRAA that would always result in the unallocated encoding path being
> taken.
>
> Hopefully everything is in order. This is only my second patch, so if a
Hi,
This is a patch that fixes a condition within disas_uncond_b_reg() related to
BRAA and BLRAA that would always result in the unallocated encoding path being
taken.
Hopefully everything is in order. This is only my second patch, so if anything
is wrong, that's my bad.
Thanks in advance for re
Am 11.01.2019 um 20:14 hat Markus Armbruster geschrieben:
> Back in September, Leonid Block added a whole bunch of macros (commit
> 540b8492618) to improve readability of qcow2.h a bit (commit
> b6a95c6d100). He later used them to fix the "vdi" driver's parameter
> cluster_size's default value (co
On Wed, Jan 23, 2019 at 04:45:54PM -0500, Ryan El Kochta wrote:
> This patch adds a new option to the input-linux object:
>
> grab-toggle=[key-combo]
Other way around: commit message describing the patch goes to the patch
(1/1), the series description (and changes to previous revisions if any)
go
This patch adds a new option to the input-linux object:
grab-toggle=[key-combo]
The key combination can be one of the following:
* ctrl-ctrl
* alt-alt
* meta-meta
* scrolllock
* ctrl-scrolllock
The user can pick any of these key combinations. The VM's grab
of the evdev device will be toggled wh
From: Balamuruhan S
Based on the discussion with Dave and David Gibson earlier with respect
to expected_downtime calculation,
https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02418.html
got suggestions that the calculation is of not accurate and we need to
consider the ram that gets re
Leonid Bloch writes:
> On 1/11/19 9:14 PM, Markus Armbruster wrote:
>> Back in September, Leonid Block added a whole bunch of macros (commit
>
> * Bloch. :)
I apologize for my carelessness. Explanation, no excuse:
$ git-log --author=armbru -Sblock -i --oneline | wc -l
167
$ git-log
On 1/11/19 9:14 PM, Markus Armbruster wrote:
> Back in September, Leonid Block added a whole bunch of macros (commit
* Bloch. :)
> 540b8492618) to improve readability of qcow2.h a bit (commit
> b6a95c6d100). He later used them to fix the "vdi" driver's parameter
> cluster_size's default value (c
Back in September, Leonid Block added a whole bunch of macros (commit
540b8492618) to improve readability of qcow2.h a bit (commit
b6a95c6d100). He later used them to fix the "vdi" driver's parameter
cluster_size's default value (commit 3dd5b8f4718). He has now
proposed a further patch[1] to auto
Following the conversations here:
https://patchwork.kernel.org/patch/10665157
and here:
https://patchwork.kernel.org/patch/10666975
Making the lookup table for power-of-two sizes auto-generated, instead
of being hard-coded into the units.h file.
I'm not sure if the changes I've made to Makefile h
Peter Maydell writes:
> On Fri, 14 Dec 2018 at 12:31, Markus Armbruster wrote:
>> Peter Maydell writes:
>> > On Fri, 14 Dec 2018 at 06:29, Markus Armbruster wrote:
>> > I have to admit I never really understood what tweak
>> > you wanted making to the commit message. I'm happy
>> > to make it
On Fri, 14 Dec 2018 at 12:31, Markus Armbruster wrote:
> Peter Maydell writes:
> > On Fri, 14 Dec 2018 at 06:29, Markus Armbruster wrote:
> > I have to admit I never really understood what tweak
> > you wanted making to the commit message. I'm happy
> > to make it clearer: do you want to suggest
Peter Maydell writes:
> On Fri, 14 Dec 2018 at 06:29, Markus Armbruster wrote:
>>
>> Paolo Bonzini writes:
>>
>> > On 13/12/18 19:21, Peter Maydell wrote:
>> >> On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
>> >>> On 13/12/18 19:01, Peter Maydell wrote:
>> I sent a patch to do this a
On 12/13/2018 04:01 PM, Peter Maydell wrote:
On Thu, 13 Dec 2018 at 17:57, Wainer dos Santos Moschetta
wrote:
Eduardo Habkost pointed out a malformed block of comments on my
patch [1] that I had ran checkpatch.pl and no warn/error was
reported. Then I realized the script does not catch such a
On Fri, 14 Dec 2018 at 06:29, Markus Armbruster wrote:
>
> Paolo Bonzini writes:
>
> > On 13/12/18 19:21, Peter Maydell wrote:
> >> On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
> >>> On 13/12/18 19:01, Peter Maydell wrote:
> I sent a patch to do this a little while back:
> https
On 14/12/18 07:29, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 13/12/18 19:21, Peter Maydell wrote:
>>> On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
On 13/12/18 19:01, Peter Maydell wrote:
> I sent a patch to do this a little while back:
> https://patchwork.kerne
Paolo Bonzini writes:
> On 13/12/18 19:21, Peter Maydell wrote:
>> On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
>>> On 13/12/18 19:01, Peter Maydell wrote:
I sent a patch to do this a little while back:
https://patchwork.kernel.org/patch/10561557/
It didn't get applied
On 13/12/18 19:21, Peter Maydell wrote:
> On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
>> On 13/12/18 19:01, Peter Maydell wrote:
>>> I sent a patch to do this a little while back:
>>> https://patchwork.kernel.org/patch/10561557/
>>>
>>> It didn't get applied because Paolo disagreed with ha
On Thu, 13 Dec 2018 at 18:07, Paolo Bonzini wrote:
> On 13/12/18 19:01, Peter Maydell wrote:
> > I sent a patch to do this a little while back:
> > https://patchwork.kernel.org/patch/10561557/
> >
> > It didn't get applied because Paolo disagreed with having
> > our tools enforcing what our style
On 13/12/18 19:01, Peter Maydell wrote:
> On Thu, 13 Dec 2018 at 17:57, Wainer dos Santos Moschetta
> wrote:
>>
>> Eduardo Habkost pointed out a malformed block of comments on my
>> patch [1] that I had ran checkpatch.pl and no warn/error was
>> reported. Then I realized the script does not catch
On Thu, 13 Dec 2018 at 17:57, Wainer dos Santos Moschetta
wrote:
>
> Eduardo Habkost pointed out a malformed block of comments on my
> patch [1] that I had ran checkpatch.pl and no warn/error was
> reported. Then I realized the script does not catch such as
> case (or it had a bug).
>
> It turns o
Eduardo Habkost pointed out a malformed block of comments on my
patch [1] that I had ran checkpatch.pl and no warn/error was
reported. Then I realized the script does not catch such as
case (or it had a bug).
It turns out that checkpatch.pl does not parse comment blocks (If I understood
its code c
This cover letter does nothing but provides hopefully useful
references to reviewers. More information on the patch itself.
Git Info:
- URI: https://github.com/clebergnu/qemu/tree/sent/set-numa-node
- Remote: https://github.com/clebergnu/qemu
- Branch: sent/set-numa-node
Travis CI Info:
V2 changes:
- checkpatch style fixes
- correct size detection of disk image placed on a file system
This driver moves virtio-blk host-side processing to kernel (via new
vhost_blk kernel driver). It accelerates virtual disk performance
close to the bare metal levels, especially for parellel loads.
On Mon, Nov 5, 2018 at 12:45 PM Michael S. Tsirkin wrote:
> I think you should Cc more widely to get meaningful
> review. At least virtio-blk and block layer core people.
Thanks, it turns out I missed the existence of qemu/scripts directory
completely.
--
wbr, Vitaly
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20181105140327.8363-1-v.mayats...@gmail.com
Subject: [Qemu-devel] [PATCH 0/1 resend] Add vhost-pci-blk driver
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total
On Mon, Nov 05, 2018 at 02:03:26PM +, Vitaly Mayatskikh wrote:
> This driver moves virtio-blk host-side processing to kernel (via new
> vhost_blk kernel driver). It accelerates virtual disk performance
> close to bare metal levels, especially for parellel loads.
>
> For example, fio numjobs=16
This driver moves virtio-blk host-side processing to kernel (via new
vhost_blk kernel driver). It accelerates virtual disk performance
close to bare metal levels, especially for parellel loads.
For example, fio numjobs=16 gets 101k randread IOPS using virtio-blk
and 1202k IOPS using vhost-blk, clo
This driver moves virtio-blk host-side processing to kernel (via new
vhost_blk kernel driver). It accelerates virtual disk performance
close to bare metal levels, especially for parellel loads.
For example, fio numjobs=16 gets 101k randread IOPS using virtio-blk
and 1202k IOPS using vhost-blk, clo
This patch adds PKU/OSPKE on Skylake-Server CPU model
Tao Xu (1):
i386: Add PKU/OSPKE on Skylake-Server CPU model
target/i386/cpu.c | 4
1 file changed, 4 insertions(+)
--
2.17.1
On Fri, Oct 05, 2018 at 02:57:03PM +0200, Dominik Csapak wrote:
> On 10/5/18 10:38 AM, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 08:56:27AM +0200, Dominik Csapak wrote:
> > > On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
> > > > On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak w
On 10/5/18 10:38 AM, Daniel P. Berrangé wrote:
On Fri, Oct 05, 2018 at 08:56:27AM +0200, Dominik Csapak wrote:
On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
this patch aims to execute a script when qemu exits
so that one can do cl
On Fri, Oct 05, 2018 at 08:56:27AM +0200, Dominik Csapak wrote:
> On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
> > On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
> > > this patch aims to execute a script when qemu exits
> > > so that one can do cleanups when using --daemonize with
On 10/4/18 3:51 PM, Daniel P. Berrangé wrote:
On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
this patch aims to execute a script when qemu exits
so that one can do cleanups when using --daemonize without
having to use the qmp monitor
IMHO the idea of cleanup scripts run by QEM
On Wed, Oct 03, 2018 at 11:13:43AM +0200, Dominik Csapak wrote:
> this patch aims to execute a script when qemu exits
> so that one can do cleanups when using --daemonize without
> having to use the qmp monitor
IMHO the idea of cleanup scripts run by QEMU itself is flawed.
QEMU will inevitably cra
Hi Dominik,
On 03/10/2018 11:13, Dominik Csapak wrote:
> this patch aims to execute a script when qemu exits
> so that one can do cleanups when using --daemonize without
> having to use the qmp monitor
>
> for now i have mostly copied the script execution code from
> the launch_script function of
this patch aims to execute a script when qemu exits
so that one can do cleanups when using --daemonize without
having to use the qmp monitor
for now i have mostly copied the script execution code from
the launch_script function of net/tap.c as i am not sure
if it would make sense to refactor that
This patch defines the new guest CPU models of Cascadelake-Server.
Tao Xu (1):
i386: Add new model of Cascadelake-Server
target/i386/cpu.c | 54 +++
1 file changed, 54 insertions(+)
--
2.17.1
Eric Blake's "[PATCH v4] tests/libqtest: Improve kill_qemu()" improves
how we report how QEMU terminated. Sadly, we bypass kill_qemu() in
certain failure modes. Fix that.
Based-on: <20180810132800.38549-1-ebl...@redhat.com>
Markus Armbruster (1):
libqtest: Improve error reporting for bad read
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180625203559.21370-1-laur...@vivier.eu
Subject: [Qemu-devel] [PATCH 0/1] target/m68k: correctly disassemble move16
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
"move16 %a0@+,%a1@" and "fmovel (cpid=3) %a0@-,%fpcr" share the same opcode...
but QEMU executes move16 (and M68040 too).
You can try:
--8<--- move16.S
.data
src:
.long 0x01020304, 0x05060708, 0x090a0b0c, 0x0d0e0f00
dst:
.lo
On 06/11/2018 06:43 PM, John Snow wrote:
> requires: 20180606182449.1607-1-js...@redhat.com
No longer requires any prerequisites.
--js
>
> See patch for details; this is somewhat an RFC that I suspect
> will be useful for libvirt in some situations, but maybe it's
> actually overkill.
>
> J
I mis-typed Vladimir's email, I have corrected it here.
On 06/11/2018 06:43 PM, John Snow wrote:
> requires: 20180606182449.1607-1-js...@redhat.com
>
> See patch for details; this is somewhat an RFC that I suspect
> will be useful for libvirt in some situations, but maybe it's
> actually overkill
requires: 20180606182449.1607-1-js...@redhat.com
See patch for details; this is somewhat an RFC that I suspect
will be useful for libvirt in some situations, but maybe it's
actually overkill.
John Snow (1):
blockdev: n-ary bitmap merge
blockdev.c | 40 ++-
1 - 100 of 375 matches
Mail list logo
