v3:
- repost with the correct tree
v2:
- rebase to master [Eric]
- add r-bs for Eric
- remove RFC tag
The VT-d code has some defects, one of them is that we cannot detect
the misuse of vIOMMU and vfio-pci early enough.
For example, logically this is not allowed:
-device intel-iommu,caching-mo
On Thu, Sep 12, 2019 at 03:00:51PM +0530, Balamuruhan S wrote:
> Hi All,
>
> This is follow-up patch that implements HOMER and OCC SRAM device
> models to emulate homer memory and occ common area access for pstate
> table, occ sensors, runtime data and slw.
>
> Currently skiboot disables the home
On Thu, Sep 12, 2019 at 11:54:00AM +0200, Cédric Le Goater wrote:
> On 12/09/2019 11:30, Balamuruhan S wrote:
> > Hi All,
> >
> > This is follow-up patch that implements HOMER and OCC SRAM device
> > models to emulate homer memory and occ common area access for pstate
> > table, occ sensors, runti
On 12/09/2019 11:30, Balamuruhan S wrote:
> Hi All,
>
> This is follow-up patch that implements HOMER and OCC SRAM device
> models to emulate homer memory and occ common area access for pstate
> table, occ sensors, runtime data and slw.
So, now, we can write directly to the OCC SRAM memory region
Hi All,
This is follow-up patch that implements HOMER and OCC SRAM device
models to emulate homer memory and occ common area access for pstate
table, occ sensors, runtime data and slw.
Currently skiboot disables the homer/occ code path with `QUIRK_NO_PBA`,
this quirk have to be removed in skiboot
Hi Peter,
I've re-based and re-tested on the post-decodetree changes. In the end
I merged the A32/T32 patches and dropped Richard's r-b as the code has
changed a bit.
Alex Bennée (3):
target/arm: handle M-profile semihosting at translate time
target/arm: handle A-profile semihosting at transl
Patchew URL: https://patchew.org/QEMU/cover.1567500411.git.lukasstra...@web.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v3 0/4] colo: Add support for continious
replication
Type: series
Message-id: cover
Hello Everyone,
These Patches add support for continious replication to colo. This means
that after the Primary fails and the Secondary did a failover, the Secondary
can then become Primary and resume replication to a new Secondary.
On a side note, I wrote a Pacemaker Resource Agent for colo which
On 8/30/2019 10:27 PM, Sergio Lopez wrote:
Jing Liu writes:
Hi Sergio,
On 8/29/2019 11:46 PM, Sergio Lopez wrote:
Jing Liu writes:
Hi Sergio,
The idea is interesting and I tried to launch a guest by your
guide but seems failed to me. I tried both legacy and normal modes,
but the vnc
Jing Liu writes:
> Hi Sergio,
>
> On 8/29/2019 11:46 PM, Sergio Lopez wrote:
>>
>> Jing Liu writes:
>>
>>> Hi Sergio,
>>>
>>> The idea is interesting and I tried to launch a guest by your
>>> guide but seems failed to me. I tried both legacy and normal modes,
>>> but the vncviewer connected and
Hi Sergio,
On 8/29/2019 11:46 PM, Sergio Lopez wrote:
Jing Liu writes:
Hi Sergio,
The idea is interesting and I tried to launch a guest by your
guide but seems failed to me. I tried both legacy and normal modes,
but the vncviewer connected and told me that:
The vm has no graphic display dev
This is ostensibly about adding docs for the g_autofree/g_autoptr
macros. As part of doing that, however, the existing HACKING doc
is merged into the CODING_STYLE doc and the text is converted to
rst with a table of contents.
Changed in v3:
- Make checkpatch.pl aware of README.rst rename
Change
Jing Liu writes:
> Hi Sergio,
>
> The idea is interesting and I tried to launch a guest by your
> guide but seems failed to me. I tried both legacy and normal modes,
> but the vncviewer connected and told me that:
> The vm has no graphic display device.
> All the screen in vnc is just black.
Th
Hi Sergio,
The idea is interesting and I tried to launch a guest by your
guide but seems failed to me. I tried both legacy and normal modes,
but the vncviewer connected and told me that:
The vm has no graphic display device.
All the screen in vnc is just black.
kernel config:
CONFIG_KVM_MMIO=y
C
Gentle ping. This should be fairly easy to review, I hope; the worst of
it is making sure that no tests remain that don't engage an entry point
in iotests.py anymore.
On 8/20/19 7:52 PM, John Snow wrote:
> This series uses python logging to enable output conditionally on
> iotests.log(). We unify
On 8/20/19 8:10 PM, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20190820235243.26092-1-js...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Type: series
>
Looks great, thanks!
I'm even squashing together 1/3/4 since it's actually quite readable and
the intermediate states aren't really bisectable.
Paolo
On 20/08/19 16:13, Peter Xu wrote:
> v3:
> - dropping patch 1 because I'm going to drop the has_coalesced_ranges
> variable later...
> - moving
Patchew URL: https://patchew.org/QEMU/20190820235243.26092-1-js...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] iotests: use python logging
Message-id: 20190820235243.26092-1-js
This series uses python logging to enable output conditionally on
iotests.log(). We unify an initialization call (which also enables
debugging output for those tests with -d) and then make the switch
inside of iotests.
It will help alleviate the need to create logged/unlogged versions
of all the v
v3:
- dropping patch 1 because I'm going to drop the has_coalesced_ranges
variable later...
- moving previous patch 2 as patch 1 because I think it's definitely
solving a standalone issue of KVM, and also it'll introduce a helper
function that will be used in follow up patches.
- added new pa
15.08.2019 18:39, Vladimir Sementsov-Ogievskiy wrote:
> 15.08.2019 17:09, Max Reitz wrote:
>> On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> Here is an asynchronous scheme for handling fragmented qcow2
>>> reads and writes. Both qcow2 read and write functions loops throu
15.08.2019 17:09, Max Reitz wrote:
> On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> Here is an asynchronous scheme for handling fragmented qcow2
>> reads and writes. Both qcow2 read and write functions loops through
>> sequential portions of data. The series aim it to paral
15.08.2019 16:21, Max Reitz wrote:
> On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote:
>> 01: - use coroutine_fn where appropriate !!!
>
> :-)
>
Ahahaha, I'll explain:
When comparing v2 vs v3 and writing this difference script I noticed
that I added coroutine_fn marks
On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is an asynchronous scheme for handling fragmented qcow2
> reads and writes. Both qcow2 read and write functions loops through
> sequential portions of data. The series aim it to parallelize these
> loops iterations.
> It imp
On 15.08.19 14:10, Vladimir Sementsov-Ogievskiy wrote:
> 01: - use coroutine_fn where appropriate !!!
:-)
signature.asc
Description: OpenPGP digital signature
Hi all!
Here is an asynchronous scheme for handling fragmented qcow2
reads and writes. Both qcow2 read and write functions loops through
sequential portions of data. The series aim it to parallelize these
loops iterations.
It improves performance for fragmented qcow2 images, I've tested it
as desc
On Thu, 25 Jul 2019 13:38:48 -0400
"Michael S. Tsirkin" wrote:
> On Thu, Jul 25, 2019 at 05:39:39PM +0200, Paolo Bonzini wrote:
> > On 25/07/19 17:01, Michael S. Tsirkin wrote:
> > >> It would be educational to try to enable ACPI core but disable all
> > >> optional features.
> >
> > A lot o
On Fri, Jul 26, 2019 at 09:57:51AM +0200, Paolo Bonzini wrote:
> On 25/07/19 22:30, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 05:35:01PM +0200, Paolo Bonzini wrote:
> >> On 25/07/19 16:46, Michael S. Tsirkin wrote:
> >>> Actually, I think I have a better idea.
> >>> At the moment we jus
On 25/07/19 22:30, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 05:35:01PM +0200, Paolo Bonzini wrote:
>> On 25/07/19 16:46, Michael S. Tsirkin wrote:
>>> Actually, I think I have a better idea.
>>> At the moment we just get an exit on these reads and return all-ones.
>>> Yes, in theory ther
On Thu, Jul 25, 2019 at 05:35:01PM +0200, Paolo Bonzini wrote:
> On 25/07/19 16:46, Michael S. Tsirkin wrote:
> > Actually, I think I have a better idea.
> > At the moment we just get an exit on these reads and return all-ones.
> > Yes, in theory there could be a UR bit set in a bunch of
> > regist
On Thu, Jul 25, 2019 at 05:39:39PM +0200, Paolo Bonzini wrote:
> On 25/07/19 17:01, Michael S. Tsirkin wrote:
> >> It would be educational to try to enable ACPI core but disable all
> >> optional features.
>
> A lot of them are select'ed so it's not easy.
>
> > Trying with ACPI_REDUCED_HARDWARE_O
On Thu, Jul 25, 2019 at 05:35:01PM +0200, Paolo Bonzini wrote:
> On 25/07/19 16:46, Michael S. Tsirkin wrote:
> > Actually, I think I have a better idea.
> > At the moment we just get an exit on these reads and return all-ones.
> > Yes, in theory there could be a UR bit set in a bunch of
> > regist
Michael S. Tsirkin writes:
> On Thu, Jul 25, 2019 at 10:58:22AM -0400, Michael S. Tsirkin wrote:
>> On Thu, Jul 25, 2019 at 04:42:42PM +0200, Sergio Lopez wrote:
>> >
>> > Paolo Bonzini writes:
>> >
>> > > On 25/07/19 15:26, Stefan Hajnoczi wrote:
>> > >> The microvm design has a premise and
On 25/07/19 17:01, Michael S. Tsirkin wrote:
>> It would be educational to try to enable ACPI core but disable all
>> optional features.
A lot of them are select'ed so it's not easy.
> Trying with ACPI_REDUCED_HARDWARE_ONLY would also be educational.
That's what the NEMU guys experimented with.
On 25/07/19 16:46, Michael S. Tsirkin wrote:
> Actually, I think I have a better idea.
> At the moment we just get an exit on these reads and return all-ones.
> Yes, in theory there could be a UR bit set in a bunch of
> registers but in practice no one cares about these,
> and I don't think we impl
On Thu, Jul 25, 2019 at 10:58:22AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 04:42:42PM +0200, Sergio Lopez wrote:
> >
> > Paolo Bonzini writes:
> >
> > > On 25/07/19 15:26, Stefan Hajnoczi wrote:
> > >> The microvm design has a premise and it can be answered definitively
> > >>
On Thu, Jul 25, 2019 at 04:42:42PM +0200, Sergio Lopez wrote:
>
> Paolo Bonzini writes:
>
> > On 25/07/19 15:26, Stefan Hajnoczi wrote:
> >> The microvm design has a premise and it can be answered definitively
> >> through performance analysis.
> >>
> >> If I had to explain to someone why PCI o
Michael S. Tsirkin writes:
> On Thu, Jul 25, 2019 at 11:05:05AM +0100, Peter Maydell wrote:
>> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
>> > OK so please start with adding virtio 1 support. Guest bits
>> > have been ready for years now.
>>
>> I'd still rather we just used pci vi
On Wed, Jul 24, 2019 at 01:14:35PM +0200, Paolo Bonzini wrote:
> On 23/07/19 12:01, Paolo Bonzini wrote:
> > The number of buses is determined by the firmware, not by QEMU, so
> > fw_cfg would not be the right interface. In fact (as I have just
> > learnt) lastbus is an x86-specific option that ov
Paolo Bonzini writes:
> On 25/07/19 15:26, Stefan Hajnoczi wrote:
>> The microvm design has a premise and it can be answered definitively
>> through performance analysis.
>>
>> If I had to explain to someone why PCI or ACPI significantly slows
>> things down, I couldn't honestly do so. I say s
On Thu, Jul 25, 2019 at 04:13:13PM +0200, Paolo Bonzini wrote:
> On 25/07/19 15:54, Michael S. Tsirkin wrote:
> >> FWIW the "PCI tax" seems to be ~10 ms in QEMU, ~10 ms in the firmware(*)
> >> and ~25 ms in the kernel.
> > How did you measure the qemu time btw?
> >
>
> It's QEMU startup, but not
On Thu, Jul 25, 2019 at 04:26:42PM +0200, Paolo Bonzini wrote:
> On 25/07/19 16:04, Peter Maydell wrote:
> > On Thu, 25 Jul 2019 at 14:43, Paolo Bonzini wrote:
> >> To me *maintainability is the biggest consideration* when introducing a
> >> new feature. "We can do just as well with q35" is a goo
On 25/07/19 16:04, Peter Maydell wrote:
> On Thu, 25 Jul 2019 at 14:43, Paolo Bonzini wrote:
>> To me *maintainability is the biggest consideration* when introducing a
>> new feature. "We can do just as well with q35" is a good reason to
>> deprecate and delete microvm, but not a good reason to r
On 25/07/19 15:54, Michael S. Tsirkin wrote:
>> FWIW the "PCI tax" seems to be ~10 ms in QEMU, ~10 ms in the firmware(*)
>> and ~25 ms in the kernel.
> How did you measure the qemu time btw?
>
It's QEMU startup, but not QEMU altogether. For example the time spent
in memory.c when a BAR is progra
On Thu, 25 Jul 2019 at 14:43, Paolo Bonzini wrote:
> To me *maintainability is the biggest consideration* when introducing a
> new feature. "We can do just as well with q35" is a good reason to
> deprecate and delete microvm, but not a good reason to reject it now as
> long as microvm is good eno
On Thu, Jul 25, 2019 at 03:43:12PM +0200, Paolo Bonzini wrote:
> On 25/07/19 15:26, Stefan Hajnoczi wrote:
> > The microvm design has a premise and it can be answered definitively
> > through performance analysis.
> >
> > If I had to explain to someone why PCI or ACPI significantly slows
> > thing
On Thu, Jul 25, 2019 at 02:26:12PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 25, 2019 at 1:10 PM Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 01:01:29PM +0100, Stefan Hajnoczi wrote:
> > > On Thu, Jul 25, 2019 at 12:23 PM Paolo Bonzini
> > > wrote:
> > > > On 25/07/19 12:42, Sergio Lo
On 25/07/19 15:26, Stefan Hajnoczi wrote:
> The microvm design has a premise and it can be answered definitively
> through performance analysis.
>
> If I had to explain to someone why PCI or ACPI significantly slows
> things down, I couldn't honestly do so. I say significantly because
> PCI init
On Thu, Jul 25, 2019 at 1:10 PM Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 01:01:29PM +0100, Stefan Hajnoczi wrote:
> > On Thu, Jul 25, 2019 at 12:23 PM Paolo Bonzini wrote:
> > > On 25/07/19 12:42, Sergio Lopez wrote:
> > > > Peter Maydell writes:
> > > >> On Thu, 25 Jul 2019 at 10:59,
On Thu, Jul 25, 2019 at 01:01:29PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 25, 2019 at 12:23 PM Paolo Bonzini wrote:
> > On 25/07/19 12:42, Sergio Lopez wrote:
> > > Peter Maydell writes:
> > >> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
> > >>> OK so please start with adding vi
On Thu, Jul 25, 2019 at 12:23 PM Paolo Bonzini wrote:
> On 25/07/19 12:42, Sergio Lopez wrote:
> > Peter Maydell writes:
> >> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
> >>> OK so please start with adding virtio 1 support. Guest bits
> >>> have been ready for years now.
> >>
> >> I
On 25/07/19 12:42, Sergio Lopez wrote:
>
> Peter Maydell writes:
>
>> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
>>> OK so please start with adding virtio 1 support. Guest bits
>>> have been ready for years now.
>>
>> I'd still rather we just used pci virtio. If pci isn't
>> fast e
On 25/07/19 12:03, Michael S. Tsirkin wrote:
>> +#ifdef CONFIG_PCI
>> +x86_platform.pci_scan_bus = kvm_pci_scan_bus;
>> +#endif
>> +
>> if (!kvm_para_available())
>> return;
>>
> Shouldn't this happen after kvm_para_available?
Actually kvm_para_available() is not needed any
Peter Maydell writes:
> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
>> OK so please start with adding virtio 1 support. Guest bits
>> have been ready for years now.
>
> I'd still rather we just used pci virtio. If pci isn't
> fast enough at startup, do something to make it faster...
On Thu, Jul 25, 2019 at 11:05:05AM +0100, Peter Maydell wrote:
> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
> > OK so please start with adding virtio 1 support. Guest bits
> > have been ready for years now.
>
> I'd still rather we just used pci virtio. If pci isn't
> fast enough at s
On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin wrote:
> OK so please start with adding virtio 1 support. Guest bits
> have been ready for years now.
I'd still rather we just used pci virtio. If pci isn't
fast enough at startup, do something to make it faster...
thanks
-- PMM
On Wed, Jul 24, 2019 at 01:14:35PM +0200, Paolo Bonzini wrote:
> On 23/07/19 12:01, Paolo Bonzini wrote:
> > The number of buses is determined by the firmware, not by QEMU, so
> > fw_cfg would not be the right interface. In fact (as I have just
> > learnt) lastbus is an x86-specific option that ov
On Wed, Jul 03, 2019 at 12:04:00AM +0200, Sergio Lopez wrote:
> On Tue, Jul 02, 2019 at 07:04:15PM +0100, Peter Maydell wrote:
> > On Tue, 2 Jul 2019 at 18:34, Sergio Lopez wrote:
> > > Peter Maydell writes:
> > > > Could we use virtio-pci instead of virtio-mmio? virtio-mmio is
> > > > a bit depr
Paolo Bonzini writes:
> On 23/07/19 12:01, Paolo Bonzini wrote:
>> The number of buses is determined by the firmware, not by QEMU, so
>> fw_cfg would not be the right interface. In fact (as I have just
>> learnt) lastbus is an x86-specific option that overrides the last bus
>> returned by SeaBI
On Tue, Jul 23, 2019 at 1:30 PM Stefano Garzarella wrote:
>
> On Tue, Jul 23, 2019 at 10:47:39AM +0100, Stefan Hajnoczi wrote:
> > On Tue, Jul 23, 2019 at 9:43 AM Sergio Lopez wrote:
> > > Montes, Julio writes:
> > >
> > > > On Fri, 2019-07-19 at 16:09 +0100, Stefan Hajnoczi wrote:
> > > >> O
On 23/07/19 12:01, Paolo Bonzini wrote:
> The number of buses is determined by the firmware, not by QEMU, so
> fw_cfg would not be the right interface. In fact (as I have just
> learnt) lastbus is an x86-specific option that overrides the last bus
> returned by SeaBIOS's handle_1ab101.
>
> So the
Currently, attaching zoned block devices (i.e., storage devices
compliant to ZAC/ZBC standards) using several virtio methods doesn't
work properly as zoned devices appear as regular block devices at the
guest. This may cause unexpected i/o errors and, potentially, some
data corruption.
To be more
On Tue, Jul 23, 2019 at 10:47:39AM +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2019 at 9:43 AM Sergio Lopez wrote:
> > Montes, Julio writes:
> >
> > > On Fri, 2019-07-19 at 16:09 +0100, Stefan Hajnoczi wrote:
> > >> On Fri, Jul 19, 2019 at 2:48 PM Sergio Lopez wrote:
> > >> > Stefan Hajnoczi
On 23/07/19 11:47, Stefan Hajnoczi wrote:
> fw_cfg could expose this information so guest kernels know when to
> stop enumerating the PCI bus. This would make all PCI guests with new
> kernels boot ~50 ms faster, regardless of machine type.
The number of buses is determined by the firmware, not b
On Tue, Jul 23, 2019 at 9:43 AM Sergio Lopez wrote:
> Montes, Julio writes:
>
> > On Fri, 2019-07-19 at 16:09 +0100, Stefan Hajnoczi wrote:
> >> On Fri, Jul 19, 2019 at 2:48 PM Sergio Lopez wrote:
> >> > Stefan Hajnoczi writes:
> >> > > On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wro
Montes, Julio writes:
> On Fri, 2019-07-19 at 16:09 +0100, Stefan Hajnoczi wrote:
>> On Fri, Jul 19, 2019 at 2:48 PM Sergio Lopez wrote:
>> > Stefan Hajnoczi writes:
>> > > On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wrote:
>> > > > Stefan Hajnoczi writes:
>> > > >
>> > > > > On T
On Fri, 2019-07-19 at 16:09 +0100, Stefan Hajnoczi wrote:
> On Fri, Jul 19, 2019 at 2:48 PM Sergio Lopez wrote:
> > Stefan Hajnoczi writes:
> > > On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wrote:
> > > > Stefan Hajnoczi writes:
> > > >
> > > > > On Tue, Jul 02, 2019 at 02:11:02PM +0
On Fri, Jul 19, 2019 at 2:48 PM Sergio Lopez wrote:
> Stefan Hajnoczi writes:
> > On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wrote:
> >>
> >> Stefan Hajnoczi writes:
> >>
> >> > On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
> >> --
> >> | Conclusion |
>
Stefan Hajnoczi writes:
> On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wrote:
>>
>> Stefan Hajnoczi writes:
>>
>> > On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
>> >> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> >> constructed after the ma
On Thu, Jul 18, 2019 at 05:21:46PM +0200, Sergio Lopez wrote:
>
> Stefan Hajnoczi writes:
>
> > On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
> >> Microvm is a machine type inspired by both NEMU and Firecracker, and
> >> constructed after the machine model implemented by the latt
Stefan Hajnoczi writes:
> On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
>> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> constructed after the machine model implemented by the latter.
>>
>> It's main purpose is providing users a KVM-only machine type wi
Thomas Huth writes:
> Let's enable the block iotests during "make check" again, to avoid that
> they get broken so easily by accident (like we've seen many times in the
> past).
Queued to testing/next, thanks.
>
> v3:
> - Added dependency for "check-block" so that the *-softmmu targets are
>
Let's enable the block iotests during "make check" again, to avoid that
they get broken so easily by accident (like we've seen many times in the
past).
v3:
- Added dependency for "check-block" so that the *-softmmu targets are
now built first
- Added 197 and 215 back to gitlab-ci.yml (there i
Am Sat, 6 Jul 2019 08:54:13 -0700 (PDT)
schrieb no-re...@patchew.org:
> Patchew URL:
> https://patchew.org/QEMU/20190706154308.7280-1-h...@tuxfamily.org/
>
> Hi,
>
> This series seems to have some coding style problems. See output
> below for more information:
[...]
> ERROR: space required after
Patchew URL: https://patchew.org/QEMU/20190706154308.7280-1-h...@tuxfamily.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190706154308.7280-1-h...@tuxfamily.org
Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] m68k: Add
During Google Summer of Code 2011, Bryce Lanham added the possibility to
emulate the NeXTcube machine in QEMU, e.g. see these URLs for some details:
https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02158.html
On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote:
> Microvm is a machine type inspired by both NEMU and Firecracker, and
> constructed after the machine model implemented by the latter.
>
> It's main purpose is providing users a KVM-only machine type with fast
> boot times, minimal att
On Tue, Jul 02, 2019 at 07:04:15PM +0100, Peter Maydell wrote:
> On Tue, 2 Jul 2019 at 18:34, Sergio Lopez wrote:
> > Peter Maydell writes:
> > > Could we use virtio-pci instead of virtio-mmio? virtio-mmio is
> > > a bit deprecated and tends not to support all the features that
> > > virtio-pci d
Peter Maydell writes:
> On Tue, 2 Jul 2019 at 13:14, Sergio Lopez wrote:
>>
>> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> constructed after the machine model implemented by the latter.
>>
>> It's main purpose is providing users a KVM-only machine type with fast
>> b
On Tue, 2 Jul 2019 at 18:34, Sergio Lopez wrote:
> Peter Maydell writes:
> > Could we use virtio-pci instead of virtio-mmio? virtio-mmio is
> > a bit deprecated and tends not to support all the features that
> > virtio-pci does. It was introduced mostly as a stopgap while we
> > didn't have pci s
Patchew URL: https://patchew.org/QEMU/20190702121106.28374-1-...@redhat.com/
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/bash
make dock
On Tue, 2 Jul 2019 at 13:14, Sergio Lopez wrote:
>
> Microvm is a machine type inspired by both NEMU and Firecracker, and
> constructed after the machine model implemented by the latter.
>
> It's main purpose is providing users a KVM-only machine type with fast
> boot times, minimal attack surface
Patchew URL: https://patchew.org/QEMU/20190702121106.28374-1-...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type
Message-id: 20190702121106.28374-1
Microvm is a machine type inspired by both NEMU and Firecracker, and
constructed after the machine model implemented by the latter.
It's main purpose is providing users a KVM-only machine type with fast
boot times, minimal attack surface (measured as the number of IO ports
and MMIO regions exposed
On 2019/5/17 下午9:47, Stefano Garzarella wrote:
This series contains some clean ups in net/net.c
The patch 1 solves an assertion failure when ipv6-prefixlen is not a number,
Following the Markus' advice, I modified the parsing of IPv6 prefix
(patch 2) and IPv4 host:port (patch 3). Then I remov
Ping.
Thanks,
Stefano
On Fri, May 17, 2019 at 3:51 PM Stefano Garzarella wrote:
>
> This series contains some clean ups in net/net.c
>
> The patch 1 solves an assertion failure when ipv6-prefixlen is not a number,
>
> Following the Markus' advice, I modified the parsing of IPv6 prefix
> (patch 2
Patchew URL:
https://patchew.org/QEMU/1561024929-26004-1-git-send-email-aleksandar.marko...@rt-rk.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v3 0/4] target/mips: Misc fixes and maintenance
for 4.1
Type
> From: Aleksandar Markovic
> Sent: Thursday, June 20, 2019 12:02 PM
> To: qemu-devel@nongnu.org
> Cc: Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH v3 0/4] target/mips: Misc fixes and maintenance for 4.1
>
> From: Aleksandar Markovic
>
> This series contains miscelaneous fixes, improv
From: Aleksandar Markovic
This series contains miscelaneous fixes, improvements, and
maintainance items intended to be integrated into QEMU 4.1.
I will gradually add patches by the end of June 2019.
v2->v3:
- amendeded two patches on cleaning checkpatch warnings
v1->v2:
- added two patche
From: "Dr. David Alan Gilbert"
Laine asked for some extra features on the network announce support;
The first allows the announce timer to announce on a subset of the
interfaces.
The second allows there to be multiple timers, each with their own
parameters (including the interface list).
Signe
v2: fix build failure with older mesa versions which don't have
EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT
Gerd Hoffmann (4):
console: add dmabuf modifier field.
vfio/display: set dmabuf modifier field
egl-helpers: add modifier support to egl_get_fd_for_texture().
egl-helpers: add modifier sup
This series contains some clean ups in net/net.c
The patch 1 solves an assertion failure when ipv6-prefixlen is not a number,
Following the Markus' advice, I modified the parsing of IPv6 prefix
(patch 2) and IPv4 host:port (patch 3). Then I removed the get_str_sep()
function (patch 4) because it
On Fri, 3 May 2019 at 11:20, Philippe Mathieu-Daudé wrote:
>
> On 5/3/19 2:22 AM, Cao Jiaxi wrote:
> > Initial Windows on ARM (AArch64 64-Bit) host support
> >
> > This series of patches is for initial support of Windows 10 on ARM as a
> > QEMU host.
> > Currently only TCG intepreter is working c
On 5/3/19 2:22 AM, Cao Jiaxi wrote:
> Initial Windows on ARM (AArch64 64-Bit) host support
>
> This series of patches is for initial support of Windows 10 on ARM as a QEMU
> host.
> Currently only TCG intepreter is working correctly, it crashes when TCG JIT
> is enabled.
>
> For now we assume i
Initial Windows on ARM (AArch64 64-Bit) host support
This series of patches is for initial support of Windows 10 on ARM as a QEMU
host.
Currently only TCG intepreter is working correctly, it crashes when TCG JIT is
enabled.
For now we assume it is built using the clang aarch64-w64-mingw32 toolc
On Wed, Apr 03, 2019 at 09:19:38PM +0300, Yuval Shaia wrote:
> On Wed, Apr 03, 2019 at 02:33:39PM +0300, Kamal Heib wrote:
> > This series implements the SRQ (Shared Receive Queue) for the pvrdma
> > device, It also includes all the needed functions and definitions for
> > support SRQ in the backen
Patchew URL:
https://patchew.org/QEMU/20190405160938.27494-1-jbi.oct...@gmail.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190405160938.27494-1-jbi.oct...@gmail.com
Subject: [Qemu-devel] [PATCH v3 0/4] target/mips: errors
This v3 improves on code alignments
Jules Irenge (4):
target/mips: realign comments to fix checkpatch warnings
target/mips: add or remove space to fix checkpatch errors
target/mips: wrap lines to fix checkpatch errors
target/mips: replace tab code indent with spaces to fix checkpatch
e
On Wed, Apr 03, 2019 at 02:33:39PM +0300, Kamal Heib wrote:
> This series implements the SRQ (Shared Receive Queue) for the pvrdma
> device, It also includes all the needed functions and definitions for
> support SRQ in the backend and resource management layers.
>
> Changes from v2->3:
> - Patch
This series implements the SRQ (Shared Receive Queue) for the pvrdma
device, It also includes all the needed functions and definitions for
support SRQ in the backend and resource management layers.
Changes from v2->3:
- Patch #1:
-- Fix commit message.
-- Remove initialization of backend_qp from r
1 - 100 of 610 matches
Mail list logo
