These traces contain some useless information (the always-0 source#) and
have no equivalents for XIVE mode. For now just remove them, and we can
put back something more sensible if and when we need it.
Signed-off-by: David Gibson
---
hw/ppc/spapr_irq.c | 4
hw/ppc/trace-events | 4
2
This method is used to set up the interrupt backends for the current
configuration. However, this means some confusing redirection between
the "dual" mode init and the init hooks for xics only and xive only modes.
Since we now have simple flags indicating whether XICS and/or XIVE are
supported, i
The only reason this parameter was needed was to work around the
inconsistent meaning of nr_irqs between xics and xive. Now that we've
fixed that, we can consistently use the number directly in the SpaprIrq
configuration.
Signed-off-by: David Gibson
---
hw/ppc/spapr_irq.c | 21 +
On 25/09/2019 08:45, David Gibson wrote:
> Every caller of spapr_vio_qirq() immediately calls qemu_irq_pulse() with
> the result, so we might as well just fold that into the helper.
>
> Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
> ---
> hw/char/spapr_vty.c| 3 +--
> hw/
spapr_irq_free() can be used to free multiple irqs at once. That's useful
for its callers, but there's no need to make the individual backend hooks
handle this. We can loop across the irqs in spapr_irq_free() itself and
have the hooks just do one at time.
Signed-off-by: David Gibson
---
hw/ppc/
spapr_xive_irq_claim() returns a bool to indicate if it succeeded. But
most of the callers and one callee use a richer Error * instead. So use
that instead of a bool return so we can actually pass more informative
errors up the stack.
In addition it didn't actually check if the irq was already c
spapr global irq numbers are different from the source numbers on the ICS
when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But
spapr_irq_set_irq_xics() was passing through the global irq number to
the ICS code unmodified.
We only got away with this because of a counteracting bug - we w
SpaprIrq::ov5 stores the value for a particular byte in PAPR option vector
5 which indicates whether XICS, XIVE or both interrupt controllers are
available. As usual for PAPR, the encoding is kind of overly complicated
and confusing (though to be fair there are some backwards compat things it
has
On Wed, Sep 25, 2019 at 11:31:30AM +0530, Aravinda Prasad wrote:
>
>
> On Wednesday 25 September 2019 07:00 AM, David Gibson wrote:
> > On Wed, Sep 18, 2019 at 01:42:34PM +0530, Aravinda Prasad wrote:
> >> Upon a machine check exception (MCE) in a guest address space,
> >> KVM causes a guest exit
Patchew URL:
https://patchew.org/QEMU/1569338511-3572-1-git-send-email-guoh...@huawei.com/
Hi,
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.
=== TEST SCRIPT
The irq claim and free paths for both XICS and XIVE check for some
validity conditions. Some of these represent genuine runtime failures,
however others - particularly checking that the basic irq number is in a
sane range - could only fail in the case of bugs in the callin code.
Therefore use asse
On 25/09/2019 08:45, David Gibson wrote:
> Interface instances should never be directly dereferenced. So, the common
> practice is to make them incomplete types to make sure no-one does that.
> XICSFrabric, however, had a dummy type which is less safe.
>
> Signed-off-by: David Gibson
> ---
> in
spapr_irq_claim() and the hooks it is based on return an integer error code
as well as taking an Error ** parameter. But none of the callers check the
integer, so we can remove it and just use the richer Error **.
Signed-off-by: David Gibson
---
hw/ppc/spapr_irq.c | 32 +
Patchew URL:
https://patchew.org/QEMU/1569338511-3572-1-git-send-email-guoh...@huawei.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
25.09.2019 2:01, John Snow wrote:
> This parameter has been deprecated since 2.12.0 and is eligible for
> removal. Remove this parameter as it is actually completely ignored;
> let's not give false hope.
>
> Signed-off-by: John Snow
> ---
> qemu-deprecated.texi | 20 +++-
> qap
On 25/09/2019 08:45, David Gibson wrote:
> spapr global irq numbers are different from the source numbers on the ICS
> when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But
> spapr_irq_set_irq_xics() was passing through the global irq number to
> the ICS code unmodified.
>
> We only got
On 25.09.19 02:16, Alex Bennée wrote:
>
> Richard Henderson writes:
>
>> It does not require going through the whole I/O path
>> in order to discard a write.
>>
>> Reviewed-by: David Hildenbrand
>> Signed-off-by: Richard Henderson
>> ---
>> include/exec/cpu-all.h| 5 -
>> include/exe
On 25/09/2019 08:45, David Gibson wrote:
> These traces contain some useless information (the always-0 source#) and
> have no equivalents for XIVE mode. For now just remove them, and we can
> put back something more sensible if and when we need it.
yes. they were always in the way of other change
On 25/09/2019 08:45, David Gibson wrote:
> This method is used to determine the name of the irq backend's node in the
> device tree, so that we can find its phandle (after SLOF may have modified
> it from the phandle we initially gave it).
>
> But, in the two cases the only difference between the
On 25/09/2019 08:45, David Gibson wrote:
> No point having a two-line helper that's used exactly once, and not likely
> to be used anywhere else in future.
>
> Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
> ---
> hw/ppc/spapr_pci.c | 3 ++-
> include/hw/pci-host/spapr.h
On 25/09/2019 08:45, David Gibson wrote:
> spapr_irq_free() can be used to free multiple irqs at once. That's useful
> for its callers, but there's no need to make the individual backend hooks
> handle this. We can loop across the irqs in spapr_irq_free() itself and
> have the hooks just do one at
On 25/09/2019 08:45, David Gibson wrote:
> Both the XICS and XIVE interrupt backends have a "nr-irqs" property, but
> it means slightly different things. For XICS (or, strictly, the ICS) it
> indicates the number of "real" external IRQs. Those start at XICS_IRQ_BASE
> (0x1000) and don't include t
On 25/09/2019 08:45, David Gibson wrote:
> Currently spapr_qirq() used to find the qemu_irq for an spapr global irq
> number, redirects through the SpaprIrq::qirq method. But the array of
> qemu_irqs is allocated in the PAPR layer, not the backends, and so the
> method implementations all return t
On 25/09/2019 08:45, David Gibson wrote:
> spapr_xive_irq_claim() returns a bool to indicate if it succeeded. But
> most of the callers and one callee use a richer Error * instead. So use
> that instead of a bool return so we can actually pass more informative
> errors up the stack.
>
> In addit
On 25/09/2019 08:45, David Gibson wrote:
> The only reason this parameter was needed was to work around the
> inconsistent meaning of nr_irqs between xics and xive. Now that we've
> fixed that, we can consistently use the number directly in the SpaprIrq
> configuration.
>
> Signed-off-by: David G
On 25/09/2019 08:45, David Gibson wrote:
> The irq claim and free paths for both XICS and XIVE check for some
> validity conditions. Some of these represent genuine runtime failures,
> however others - particularly checking that the basic irq number is in a
> sane range - could only fail in the ca
On 25/09/2019 08:45, David Gibson wrote:
> This method is used to set up the interrupt backends for the current
> configuration. However, this means some confusing redirection between
> the "dual" mode init and the init hooks for xics only and xive only modes.
>
> Since we now have simple flags i
On 25/09/2019 08:45, David Gibson wrote:
> spapr_irq_claim() and the hooks it is based on return an integer error code
> as well as taking an Error ** parameter. But none of the callers check the
> integer, so we can remove it and just use the richer Error **.
>
> Signed-off-by: David Gibson
Re
24.09.2019 23:38, Eric Blake wrote:
> On 9/24/19 3:08 PM, Vladimir Sementsov-Ogievskiy wrote:
>> fit_load_fdt forget to zero errp. Fix it.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> Reviewed-by: Eric Blake
>> ---
>> hw/core/loader-fit.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>>
Gerd Hoffmann writes:
> Hi,
>
>> +microvm.kernel-cmdline=bool (Set off to disable adding virtio-mmio devices
>> to the kernel cmdline)
>
> Hmm, is that the long-term plan? IMO the virtio-mmio devices should be
> discoverable somehow. ACPI, or device-tree, or fw_cfg, or ...
I'd say that dep
On 25/09/2019 08:45, David Gibson wrote:
> SpaprIrq::ov5 stores the value for a particular byte in PAPR option vector
> 5 which indicates whether XICS, XIVE or both interrupt controllers are
> available. As usual for PAPR, the encoding is kind of overly complicated
> and confusing (though to be fa
On 25/09/2019 08:45, David Gibson wrote:
> We create a subtype of TYPE_ICS specifically for sPAPR. For now all this
> does is move the setup of the PAPR specific hcalls and RTAS calls to
> the realize() function for this, rather than requiring the PAPR code to
> explicitly call xics_spapr_init().
25.09.2019 10:23, Vladimir Sementsov-Ogievskiy wrote:
> 24.09.2019 23:38, Eric Blake wrote:
>> On 9/24/19 3:08 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> fit_load_fdt forget to zero errp. Fix it.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>>> Reviewed-by: Eric Blake
>>> ---
>>> hw/cor
On 25/09/2019 08:45, David Gibson wrote:
> Currently TYPE_XICS_BASE and TYPE_XICS_SIMPLE have their own reset methods,
> using the standard technique for having the subtype call the supertype's
> methods before doing its own thing.
>
> But TYPE_XICS_SIMPLE is the only subtype of TYPE_XICS_BASE eve
On Wed, 25 Sep 2019 08:55:50 +0200
Cédric Le Goater wrote:
> On 25/09/2019 08:45, David Gibson wrote:
> > Interface instances should never be directly dereferenced. So, the common
> > practice is to make them incomplete types to make sure no-one does that.
> > XICSFrabric, however, had a dummy t
On 24.09.19 14:44, 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 minimalist machine type free
> from the burden of legacy compatibility, serving
On Wed, 25 Sep 2019 16:45:15 +1000
David Gibson wrote:
> Interface instances should never be directly dereferenced. So, the common
> practice is to make them incomplete types to make sure no-one does that.
> XICSFrabric, however, had a dummy type which is less safe.
>
> Signed-off-by: David Gib
25.09.2019 0:12, Eric Blake wrote:
> On 9/24/19 3:09 PM, Vladimir Sementsov-Ogievskiy wrote:
>> If we want append hint to errp, we must use ERRP_FUNCTION_BEGIN macro.
>> Otherwise hint will not be appended in case of errp == &fatal_err
>> (program will exit before error_append_hint() call). Fix suc
On 24.09.19 16:47, Igor Mammedov wrote:
> Changelog:
> since v6:
> - include and rebase on top of
>[PATCH 0/2] kvm: clear dirty bitmaps from all overlapping memslots
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg646200.html
> - minor fixups suggested during v6 re
On 25/09/19 07:49, Sergio Lopez wrote:
>>> +serving as a stepping stone
>>> +for future projects aiming at improving boot times, reducing the
>>> +attack surface and slimming down QEMU's footprint.
>>
>> "Microvm also establishes a baseline for benchmarking QEMU and operating
>> systems, since it i
> On 24.09.19 14:44, 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 minimalist machine type free
> > from the burden of legacy compatibi
On 24/09/2019 20.49, John Snow wrote:
> Nobody was making movement on this patch series, and in response to Max
> acking the whole series, I was just going to send a pull request for the
> whole thing and see who barked, because nobody likes or hates this
> series enough to offer any feedback.
>
>
On Wed, 25 Sep 2019 16:45:18 +1000
David Gibson wrote:
> Currently TYPE_XICS_BASE and TYPE_XICS_SIMPLE have their own reset methods,
> using the standard technique for having the subtype call the supertype's
> methods before doing its own thing.
>
> But TYPE_XICS_SIMPLE is the only subtype of TY
Patchew URL: https://patchew.org/QEMU/20190924194501.9303-1-cr...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190924194501.9303-1-cr...@redhat.com
Subject: [PATCH 0/3] Acceptance tests: make better use
David Hildenbrand writes:
> On 24.09.19 14:44, 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 minimalist machine type free
>> from the burd
On 2019/9/24 23:39, Michael S. Tsirkin wrote:
On Tue, Sep 24, 2019 at 11:21:40PM +0800, Heyi Guo wrote:
Import Linux header file include/uapi/linux/arm_sdei.h from kernel
v5.3 release.
This is to prepare for qemu SDEI emulation.
Signed-off-by: Heyi Guo
Cc: Peter Maydell
Cc: Dave Martin
C
What does v20171217 refer to? A pre-built binary? Windows? Linux? Mac
OS? ... sorry, but you have to be a little bit more specific.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824704
Title:
-k t
On 25.09.19 10:10, Sergio Lopez wrote:
>
> David Hildenbrand writes:
>
>> On 24.09.19 14:44, 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 user
On Wed, 25 Sep 2019 16:45:19 +1000
David Gibson wrote:
> TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
> instantiated, and the only one we're ever likely to want. The
> existence of different classes is just a hang over from when we
> (misguidedly) had separate subtypes for th
We have found a vm that recovered from a freeze and it seems like it has jumped
in time.
Below I have pasted a dump of tty1, it is ocr'd though so some characters could
have been misinterpreted.
hild
[13198552.767867] le-rss:010 Killed process 10374 (crop) total,r,4376400,
anon-rss,018, tl [13
On 25/09/19 10:10, Sergio Lopez wrote:
> That would be great. I'm also looking forward for virtio-mem (and an
> hypothetical virtio-cpu) to eventually gain hotplug capabilities in
> microvm.
I disagree with this. virtio is not a silver bullet (and in fact
perhaps it's just me but I've never under
On Wed, 25 Sep 2019 10:16:10 +0200
Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:19 +1000
> David Gibson wrote:
>
> > TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
> > instantiated, and the only one we're ever likely to want. The
Hi Sergio,
On Tue, Sep 24, 2019 at 02:44:26PM +0200, Sergio Lopez wrote:
> Extract PVH related functions from pc.c, and put them in pvh.c, so
> they can be shared with other components.
>
> Signed-off-by: Sergio Lopez
> ---
> hw/i386/Makefile.objs | 1 +
> hw/i386/pc.c | 120 +---
> >>> 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 minimalist machine type free
> >>> from the burden of legacy compatibility, serving as a stepping ston
On Wed, 25 Sep 2019 16:45:20 +1000
David Gibson wrote:
> We create a subtype of TYPE_ICS specifically for sPAPR. For now all this
> does is move the setup of the PAPR specific hcalls and RTAS calls to
> the realize() function for this, rather than requiring the PAPR code to
> explicitly call xic
Paolo Bonzini writes:
> On 25/09/19 07:49, Sergio Lopez wrote:
+serving as a stepping stone
+for future projects aiming at improving boot times, reducing the
+attack surface and slimming down QEMU's footprint.
>>>
>>> "Microvm also establishes a baseline for benchmarking QEMU and
Hi Tao,
Typo in the commit title and message? s/marco/macro?
On Tue, Sep 24, 2019 at 09:02:09AM +0800, Tao Xu wrote:
> Drop the duplicated definition of cpuid AVX512_VBMI and marco and
I'm not native speaker but I'd remove some 'and' ^ this
> rename it as CPUID_7_0_ECX_AVX512_VBMI. And rena
Paolo Bonzini writes:
> On 25/09/19 10:10, Sergio Lopez wrote:
>> That would be great. I'm also looking forward for virtio-mem (and an
>> hypothetical virtio-cpu) to eventually gain hotplug capabilities in
>> microvm.
>
> I disagree with this. virtio is not a silver bullet (and in fact
> perhap
On 25.09.19 10:26, Paolo Bonzini wrote:
> On 25/09/19 10:10, Sergio Lopez wrote:
>> That would be great. I'm also looking forward for virtio-mem (and an
>> hypothetical virtio-cpu) to eventually gain hotplug capabilities in
>> microvm.
>
> I disagree with this. virtio is not a silver bullet (and
Hi,
> For microvm that's simply not worth it. Fiddling with the command line
> achieves the same result without any significant drawbacks,
Assuming you actually can fiddle with the command line, which is only
the case with direct kernel boot.
> > To fix that the firmware must be able to find t
On Wed, 25 Sep 2019 16:45:21 +1000
David Gibson wrote:
> No point having a two-line helper that's used exactly once, and not likely
> to be used anywhere else in future.
>
> Signed-off-by: David Gibson
> ---
Reviewed-by: Greg Kurz
> hw/ppc/spapr_pci.c | 3 ++-
> include/hw/pci-host
On 25/09/2019 10:40, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:20 +1000
> David Gibson wrote:
>
>> We create a subtype of TYPE_ICS specifically for sPAPR. For now all this
>> does is move the setup of the PAPR specific hcalls and RTAS calls to
>> the realize() function for this, rather than r
On Wed, 25 Sep 2019 16:45:22 +1000
David Gibson wrote:
> Every caller of spapr_vio_qirq() immediately calls qemu_irq_pulse() with
> the result, so we might as well just fold that into the helper.
>
> Signed-off-by: David Gibson
> ---
Reviewed-by: Greg Kurz
> hw/char/spapr_vty.c| 3 +
Alistair Francis writes:
> On Mon, Sep 23, 2019 at 2:46 PM Peter Maydell
> wrote:
>>
>> On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote:
>> > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng wrote:
>> > > I don't think we should mirror what is used on ARM virt board to
>> > > create 2 flash for
Stefano Garzarella writes:
> Hi Sergio,
>
> On Tue, Sep 24, 2019 at 02:44:26PM +0200, Sergio Lopez wrote:
>> Extract PVH related functions from pc.c, and put them in pvh.c, so
>> they can be shared with other components.
>>
>> Signed-off-by: Sergio Lopez
>> ---
>> hw/i386/Makefile.objs | 1
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Am 20.09.2019 um 09:25 hat Pavel Dovgalyuk geschrieben:
> > > From: Kevin Wolf [mailto:kw...@redhat.com]
> > > Am 19.09.2019 um 14:10 hat Pavel Dovgalyuk geschrieben:
> > > > > From: Kevin Wolf [mailto:kw...@redhat.com]
> > > > > diff --git a/block/blo
On Wed, 25 Sep 2019 10:55:35 +0200
Cédric Le Goater wrote:
> On 25/09/2019 10:40, Greg Kurz wrote:
> > On Wed, 25 Sep 2019 16:45:20 +1000
> > David Gibson wrote:
> >
> >> We create a subtype of TYPE_ICS specifically for sPAPR. For now all this
> >> does is move the setup of the PAPR specific h
On Wed, Sep 25, 2019 at 1:35 PM Bin Meng wrote:
>
> On Wed, Sep 25, 2019 at 12:49 PM wrote:
> >
> > From: Guo Ren
> >
>
> nits: the title is probably better to be rephrased to: Ignore reserved
> bits when calculating PPN for RV64
Yes, I forgot change the title.
>
> > Highest 10 bits of PTE are
Hi,
> If you want to add hotplug to microvm, you can reuse the existing code
> for CPU and memory hotplug controllers, and write drivers for them in
> Linux's drivers/platform. The drivers would basically do what the ACPI
> AML tells the interpreter to do.
How would the linux kernel detect tho
From: Guo Ren
Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
need to ignore them. They cannot be a part of ppn.
1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
4.4 Sv39: Page-Based 39-bit Virtual-Memory System
4.5 Sv48: Page-Based 48-bit V
"Dr. David Alan Gilbert (git)" writes:
> From: "Dr. David Alan Gilbert"
>
> Various parts of the migration code do different things when they're
> in postcopy mode; prior to this patch this has been 'postcopy-active'.
> This patch extends 'in_postcopy' to include 'postcopy-paused' and
> 'postcop
On 25/09/19 10:40, Sergio Lopez wrote:
>>> We need the PIT for non-KVM accel (if present with KVM and
>>> kernel_irqchip_split = off, it basically becomes a placeholder)
>> Why?
>
> Perhaps I'm missing something. Is some other device supposed to be
> acting as a HW timer while running with TCG acc
On 25/09/19 11:12, Gerd Hoffmann wrote:
> Hi,
>
>> If you want to add hotplug to microvm, you can reuse the existing code
>> for CPU and memory hotplug controllers, and write drivers for them in
>> Linux's drivers/platform. The drivers would basically do what the ACPI
>> AML tells the interpret
On Wed, Sep 25, 2019 at 11:00:30AM +0200, Sergio Lopez wrote:
> Stefano Garzarella writes:
> > Hi Sergio,
> >
> > On Tue, Sep 24, 2019 at 02:44:26PM +0200, Sergio Lopez wrote:
> >> Extract PVH related functions from pc.c, and put them in pvh.c, so
> >> they can be shared with other components.
> >
On 25.09.19 11:12, Gerd Hoffmann wrote:
> Hi,
>
>> If you want to add hotplug to microvm, you can reuse the existing code
>> for CPU and memory hotplug controllers, and write drivers for them in
>> Linux's drivers/platform. The drivers would basically do what the ACPI
>> AML tells the interpret
"Zoltán Kővágó" writes:
> On 2019-09-23 15:08, Markus Armbruster wrote:
>> "Kővágó, Zoltán" writes:
>>
>>> This will allow us to disable mixeng when we use a decent backend.
>>>
>>> Disabling mixeng have a few advantages:
>>> * we no longer convert the audio output from one format to another, wh
* Marc-André Lureau (marcandre.lur...@redhat.com) wrote:
> Signed-off-by: Marc-André Lureau
I've queued this 1/6 only.
> ---
> migration/qjson.h | 2 ++
> migration/savevm.c | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/migration/qjson.h b/migration/qjson.h
> in
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> Three patches to cleanup postcopy:
>
> [1]: split canonicalize bitmap and discard page
> [2]: remove unsentmap since it is not necessary
> [3]: cleanup the get_queued_page_not_dirty
Queued
>
> Wei Yang (3):
> migration/postcopy: not necessar
On Wed, Sep 25, 2019 at 5:21 PM wrote:
>
> From: Guo Ren
>
> Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
> need to ignore them. They cannot be a part of ppn.
>
> 1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
>4.4 Sv39: Page-Based 39-bit
Patchew URL:
https://patchew.org/QEMU/20190924200902.4703-1-vsement...@virtuozzo.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190924200902.4703-1-vsement...@virtuozzo.com
Subject: [PATCH v3 00/25] error: auto
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> Hi,
> This fixes a deadlock that can occur on the source after
> a failed RDMA migration and cleans up some warning messages
> that can appear during normal completion.
>
> https://bugzilla.redhat.
23.09.2019 14:57, Max Reitz wrote:
> Sometimes it is useful to be able to add a node to the block graph that
> takes or unshare a certain set of permissions for debugging purposes.
> This patch adds this capability to blkdebug.
>
> (Note that you cannot make blkdebug release or share permissions t
25.09.2019 13:09, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190924200902.4703-1-vsement...@virtuozzo.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
[..]
>
> === OUTPUT BEGIN ===
> 1/25 Chec
This is a tangent, but I was a bit too harsh in my previous message (at
least it made you laugh rather than angry!) so I think I owe you an
explanation.
On 25/09/19 10:44, David Hildenbrand wrote:
> I consider virtio the silver bullet whenever we want a mature
> paravirtualized interface across ar
Thanks Thomas,
Resubmitting the tests, all other code will remain the same.
Sam
On Wed, Sep 25, 2019 at 10:58 AM Thomas Huth wrote:
> On 24/09/2019 20.49, John Snow wrote:
> > Nobody was making movement on this patch series, and in response to Max
> > acking the whole series, I was just going
Hi Sam Eiderman via!
We received your email, but were unable to deliver it because it
contains HTML. HTML emails are not permitted. The following guide can
help you configure your client to send in plain text instead:
https://useplaintext.email
If you have any questions, please reply to this ema
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> This patch uses glib's g_auto mechanism to automatically free
> rcu_read_lock's at the end of the block. Given that humans
> have a habit of forgetting an error path somewhere it's
> best to leave it
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> Alex noticed that some of the postcopy tests would occasionally
> hang; this series adds some checks to make them more likely
> to assert than hang in some failure cases, and changes
> the migration b
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> Various parts of the migration code do different things when they're
> in postcopy mode; prior to this patch this has been 'postcopy-active'.
> This patch extends 'in_postcopy' to include 'postcopy-pa
On 25.09.19 12:19, Paolo Bonzini wrote:
> This is a tangent, but I was a bit too harsh in my previous message (at
> least it made you laugh rather than angry!) so I think I owe you an
> explanation.
It's hard to make me really angry, you have to try better :) However,
after years of working on VMs
Paolo Bonzini writes:
> On 25/09/19 10:40, Sergio Lopez wrote:
We need the PIT for non-KVM accel (if present with KVM and
kernel_irqchip_split = off, it basically becomes a placeholder)
>>> Why?
>>
>> Perhaps I'm missing something. Is some other device supposed to be
>> acting as a HW
From: Sam Eiderman
Fixing tabbing in block related macros.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
hw/ide/qdev.c| 2 +-
include/hw/block/block.h | 16
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/id
v1:
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56
From: Sam Eiderman
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not support unplugging.
Signed-off-by: Sam Eiderman
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
bootdevice.c| 55 +
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most l
From: Sam Eiderman
Add QTest tests to check the logical geometry override option.
The tests in hd-geo-test are out of date - they only test IDE and do not
test interesting MBRs.
I added a few helper functions which will make adding more tests easier.
QTest's fw_cfg helper functions support onl
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
In future commits we will use the provided LCH
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
hw/scsi/scsi-bus.c | 16
include/hw/scsi/scsi.h | 1 +
1 - 100 of 402 matches
Mail list logo
