From: Richard Henderson
We were eliding all zero indexes. It is only ld==0 that does
not have an index in the instruction. This also allows us to
avoid breaking the final print into multiple pieces.
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-1
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-5-ys...@users.sourceforge.jp>
Signed-off-by: Richard Henderson
---
include/disas/dis-asm.h |5 +
target/rx/disas.c | 1480 +
v21 changes
Add cpu-param.h
Remove CPU_COMMON
rx_load_image move to rx-virt.
remove rx_load_image
Signed-off-by: Yoshinori Sato
Message-Id: <20190616142836.10614-4-ys...@users.sourceforge.jp>
Reviewed-by: Richard Henderson
Message-Id: <20190607091116.49044-4-ys...@users.sourceforge.jp>
Signed-o
From: Richard Henderson
Many of the multi-part prints have been eliminated by previous
patches. Eliminate the rest of them.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-22-ys...@users.sourceforge.jp>
Tested-by
Signed-off-by: Yoshinori Sato
Message-Id: <20190616142836.10614-3-ys...@users.sourceforge.jp>
Reviewed-by: Richard Henderson
Message-Id: <20190607091116.49044-3-ys...@users.sourceforge.jp>
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
[PMD: Removed tlb_fill, extracted from
On Fri, 27 Sep 2019 15:51:04 +1000
David Gibson wrote:
> On Thu, Sep 26, 2019 at 05:35:39PM +0200, Greg Kurz wrote:
> > On Thu, 26 Sep 2019 09:05:56 +0200
> > Cédric Le Goater wrote:
> >
> > > >>> +if (spapr->irq->xive) {
> > > >>> +uint32_t nr_servers = spapr_max_server_number(spap
From: Richard Henderson
Issue an error if no kernel, no bios, and not qtest'ing.
Fixes make check-qtest-rx: test/qom-test.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-16-ys...@users.sourceforge.jp>
Tested-by: Philippe Mathieu-Daudé
Signe
On Thu, Sep 26, 2019 at 12:07:54PM -0700, Richard Henderson wrote:
> On 9/24/19 4:31 AM, Andrew Jones wrote:
> > +static uint32_t sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
> > +{
> > +uint32_t start_vq = (start_len & 0xf) + 1;
> > +
> > +return arm_cpu_vq_map_next_smaller(cpu,
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-17-ys...@users.sourceforge.jp>
Signed-off-by: Richard Henderson
pick ed65c02993 target/rx: Add RX to SysEmuTarget
pick 01372568ae tests: Add rx to machine-none-t
From: Philippe Mathieu-Daudé
Add two tests for the rx-virt machine, based on the recommended test
setup from Yoshinori Sato:
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03586.html
- U-Boot prompt
- Linux kernel with Sash shell
These are very quick tests:
$ avocado run -t arch:rx
From: Philippe Mathieu-Daudé
Some RX peripheral using 8bit and 16bit registers.
Added 8bit and 16bit APIs.
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-11-ys...@users.sourceforge.jp>
Tested-by: Philippe Math
This part only supported RXv1 instructions.
Instruction manual.
https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01us0032ej0120_rxsm.pdf
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-2-ys...@users
From: Richard Henderson
Collected, to be used in the next patch.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-23-ys...@users.sourceforge.jp>
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-10-ys...@users.sourceforge.jp>
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
include/qemu/bitops.h | 38 +
Hello.
This patch series is added Renesas RX target emulation.
Changes for v24.
Add note for qapi/machine.json.
Added Acked-by for 6/22.
git rebase master.
Changes for v23.
Follow master changes.
Changes for v22.
Added some include.
Changes for v21.
rebase latest master.
Remove unneeded hmp_inf
From: Richard Henderson
There are so many different forms of each RX instruction
that it will be very useful to be able to look at the bytes
to see on which path a bug may lie.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <201906070
Signed-off-by: Yoshinori Sato
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-18-ys...@users.sourceforge.jp>
Signed-off-by: Richard Henderson
---
MAINTAINERS | 19 +++
1 file changed, 19 insertions(+)
diff --git a/MAINTAINER
renesas_tmr: 8bit timer modules.
renesas_cmt: 16bit compare match timer modules.
This part use many renesas's CPU.
Hardware manual.
https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01uh0033ej0140_rx62n.pdf
Signed-off-by: Yoshinori Sato
Reviewed-by: Alex Bennée
Reviewed-by: Philip
On Fri, Sep 27, 2019 at 12:58:38PM +0800, qi1.zh...@intel.com wrote:
> From: "Zhang, Qi"
>
> When dt is supported, TM field should not be Reserved(0).
>
> Refer to VT-d Spec 9.8
>
> Signed-off-by: Zhang, Qi
> Signed-off-by: Qi, Yadong
> ---
> hw/i386/intel_iommu.c | 12 ++--
From: Richard Henderson
Note that the ld == 3 case handled by prt_ldmi is decoded as
XCHG_rr and cannot appear here.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49044-21-ys...@users.sourceforge.jp>
Tested-by: Philip
This module supported only non FIFO type.
Hardware manual.
https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01uh0033ej0140_rx62n.pdf
Signed-off-by: Yoshinori Sato
Reviewed-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190607091116.49044-8-ys...@users.sourcef
The remaining logic in the post_load hook really belongs to the interrupt
controller backends, and just needs to be called on the active controller
(after the active controller is set to the right thing based on the
incoming migration in the generic spapr_irq_post_load() logic).
Signed-off-by: Dav
From: Richard Henderson
This has consistency with prt_ri(). It loads all data before
beginning output. It uses exactly one call to prt() to emit
the full instruction.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Yoshinori Sato
Signed-off-by: Yoshinori Sato
Message-Id: <20190607091116.49
Thank you for checking this issue.
I looked at the ptimer code, like you said. Just one question: isn't this used
by other hw as well?
Maybe this problem is more general...
I also tried (basically) the same example on a aarch64 (raspberry pi3),
and I don't find any problems there. Maybe could be
The nr_msis value we use here has to line up with whether we're using
legacy or modern irq allocation. Therefore it's safer to derive it based
on legacy_irq_allocation rather than having SpaprIrq contain a canned
value.
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 5 ++---
hw/
Signed-off-by: Yoshinori Sato
---
qapi/machine.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/qapi/machine.json b/qapi/machine.json
index ca26779f1a..4409c113c2 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -21,6 +21,7 @@
#is true even for "qemu-sy
On Thu, Sep 26, 2019 at 05:35:39PM +0200, Greg Kurz wrote:
> On Thu, 26 Sep 2019 09:05:56 +0200
> Cédric Le Goater wrote:
>
> > >>> +if (spapr->irq->xive) {
> > >>> +uint32_t nr_servers = spapr_max_server_number(spapr);
> > >>> +DeviceState *dev;
> > >>> +int i;
> > >>
This hook is a bit odd. The only caller is spapr_irq_init_kvm(), but
it explicitly takes an SpaprIrq *, so it's never really called through the
current SpaprIrq. Essentially this is just a way of passing through a
function pointer so that spapr_irq_init_kvm() can handle some
configuration and err
From: Philippe Mathieu-Daudé
While the VIRT machine can use different microcontrollers,
the RX62N microcontroller is tied to the RX62N CPU core.
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Yoshinori Sato
---
hw/rx/rx-virt.c | 8
1 file changed, 8 insertions(+)
diff --git a/
For the benefit of peripheral device allocation, the number of available
irqs really wants to be the same on a given machine type version,
regardless of what irq backends we are using. That's the case now, but
only because we make sure the different SpaprIrq instances have the same
value except fo
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
It turns out that all the logic in the SpaprIrq::reset hooks (and some in
the SpaprIrq::post_load hooks) isn't really related to resetting the irq
backend (that's handled by the backends' own reset routines). Rather its
about getting the backend ready to be the active interrupt controller or
stopp
This method depends only on the active irq controller. Now that we've
formalized the notion of active controller we can dispatch directly
through that, rather than dispatching via SpaprIrq with the dual
version having to do a second conditional dispatch.
Signed-off-by: David Gibson
---
hw/intc/
spapr_xive_irq_claim() returns a bool to indicate if it succeeded.
But most of the callers and one callee use int return values and/or an
Error * with more information instead. In any case, ints are a more
common idiom for success/failure states than bools (one never knows
what sense they'll be in
These methods, like cpu_intc_create, really belong to the interrupt
controller, but need to be called on all possible intcs.
Like cpu_intc_create, therefore, make them methods on the intc and
always call it for all existing intcs.
Signed-off-by: David Gibson
---
hw/intc/spapr_xive.c| 7
This method depends only on the active irq controller. Now that we've
formalized the notion of active controller we can dispatch directly
through that, rather than dispatching via SpaprIrq with the dual
version having to do a second conditional dispatch.
Signed-off-by: David Gibson
---
hw/intc/
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 node name is the
presence of a unit address. Searc
Both XICS and XIVE have routines to connect and disconnect KVM with similar
but not identical signatures. This adjusts them to match exactly, which
will be useful for further cleanups later.
While we're at it, remove error reporting from the disconnect path. In the
XICS case this wasn't used at
The only thing remaining in this structure are the flags to allow either
XICS or XIVE to be present. These actually make more sense as spapr
capabilities - that way they can take advantage of the existing
infrastructure to sanity check capability states across migration and so
forth.
Signed-off-b
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
This method depends only on the active irq controller. Now that we've
formalized the notion of active controller we can dispatch directly through
that, rather than dispatching via SpaprIrq with the dual version having
to do a second conditional dispatch.
Signed-off-by: David Gibson
---
hw/intc/
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
Reviewed-by: Cédric Le Goater
---
hw/ppc/spa
This method essentially represents code which belongs to the interrupt
controller, but needs to be called on all possible intcs, rather than
just the currently active one. The "dual" version therefore calls
into the xics and xive versions confusingly.
Handle this more directly, by making it inste
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(). In future it will have some more
function.
Sign
spapr now has the mechanism of constructing both XICS and XIVE instances of
the SpaprInterruptController interface. However, only one of the interrupt
controllers will actually be active at any given time, depending on feature
negotiation with the guest. This is handled in the current code via
sp
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 the special IPI vector. For XIVE, however, it
inc
The SpaprIrq structure is used to represent ths spapr machine's irq
backend. Except that it kind of conflates two concepts: one is the
backend proper - a specific interrupt controller that we might or
might not be using, the other is the irq configuration which covers
the layout of irq space and w
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
Reviewed-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
---
hw/char/spapr_vty.c| 3 +--
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
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
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
Reviewed-by:
TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
instantiated. The existence of different classes is mostly a hang
over from when we (misguidedly) had separate subtypes for the KVM and
non-KVM version of the device.
There could be some call for an abstract base type for ICS varian
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 ever
instantiated, so there's no point having the spli
This is a substantial rework to clean up the handling of IRQs in
spapr. It includes some cleanups to both the XICS and XIVE interrupt
controller backends, as well as more to the common spapr irq handling
infrastructure.
Changes since v1:
* Lots of extra patches
* Many minor adjustments based on
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
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
Reviewed-by
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
Reviewed-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
---
hw/ppc/spapr_pci.c | 3 ++-
include/hw/pci-host/spap
Currently ics_reject(), ics_resend() and ics_eoi() indirect through
class methods. But there's only one implementation of each method,
the one in TYPE_ICS_SIMPLE. TYPE_ICS_BASE has no implementation, but
it's never instantiated, and has no other subtypes.
So clean up by eliminating the method an
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.
We were also using OBJECT_CHECK() where we should have been using
INTERFACE_CHECK().
Signe
Currently spapr_qirq(), whic is 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 the same thing,
just differing in the pre
There are a number of ics_simple_*() functions that aren't actually
specific to TYPE_XICS_SIMPLE at all, and are equally valid on
TYPE_XICS_BASE. Rename them to ics_*() accordingly.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/intc/trace-events | 6
From: "Zhang, Qi"
When dt is supported, TM field should not be Reserved(0).
Refer to VT-d Spec 9.8
Signed-off-by: Zhang, Qi
Signed-off-by: Qi, Yadong
---
hw/i386/intel_iommu.c | 12 ++--
hw/i386/intel_iommu_internal.h | 25 +++--
2 files changed, 25 inser
25.09.2019. 17.53, "Philippe Mathieu-Daudé" је
написао/ла:
>
> On 9/25/19 2:45 PM, Aleksandar Markovic wrote:
> > From: Aleksandar Markovic
> >
> > Mostly fix errors and warnings reported by 'checkpatch.pl -f'.
> >
> > Signed-off-by: Aleksandar Markovic
> > ---
> > target/mips/helper.c | 132
++
On Fri, Sep 27, 2019 at 8:55 AM Alistair Francis
wrote:
typo "privledge" in the commit title
>
> Signed-off-by: Alistair Francis
> ---
> target/riscv/translate.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index adeddb85
On Thu, Sep 26, 2019 at 10:36:02AM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:31 +1000
> 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 w
QEMU does not allocate PCI resources (BARs) in any case - coldplug devices
are configured by the firmware and hotplug devices rely on the guest
system to do the assignment via the PCI rescan mechanism. Also in order
to create non empty "assigned-addresses", the device has to be enabled
(i.e. PCI_CO
Public bug reported:
I am trying to access the CDROM (iso) from QEMU using FreeDOS and I get
an error when doing a directory for:
i can boot from the iso but if i exit to access the files from the CDROM
ISO i get the attached error.
I believe there is an issue with the QEMU for the Raspberry Pi.
Patchew URL:
https://patchew.org/QEMU/919bbd6e0557d2fe2d9c17de394cc0b4c6fa4426.1569445204.git.tgole...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id:
919bbd6e0557d2fe2d9c17de394cc0b4c6fa4426.1569445204.git
On 9/26/19 8:17 AM, Lakshmi Ramasubramanian wrote:
The following commit for ARM Trusted Firmware for QEMU virt ARMv8-A
is almost 3 years old
https://salsa.debian.org/debian/atf-allwinner/commit/b6b671c4ac4bd5595306863225bb3bece1e6135c
Current limitations:
* Only cold boot is supported
* No buil
Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
from the ARM Virt board and the implementation is based on the ARM Virt
board. This allows users to specify flash files from the command line.
Signed-off-by: Alistair Francis
---
hw/riscv/Kconfig| 1 +
hw/riscv/virt.
If the user supplied pflash to QEMU then change the reset code to jump
to the pflash base address instead of the DRAM base address.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
---
hw/riscv/virt.c | 11 ++-
1 file changed, 10 insertions(+),
Add a property that when set to true QEMU will jump from the ROM code to
the start of flash memory instead of DRAM which is the default
behaviour.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_u.c | 27 +++
include/hw/riscv/sifive_u.h | 2 ++
2 files change
Signed-off-by: Alistair Francis
---
target/riscv/translate.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index adeddb85f6..537af0003e 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -810,7 +810,14 @@ static
On reset only a single L2 cache way is enabled, the others are exposed
as memory that can be used by early boot firmware. This L2 region is
generally disabled using the WayEnable register at a later stage in the
boot process. To allow firmware to target QEMU and the HiFive Unleashed
let's add the L
Instead of using the DEFINE_MACHINE() macro to define the machine let's
do it manually. This allows us to specify machine properties.
This patch is no functional change.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_u.c | 44 ++---
include/hw/riscv/
The HiFive Unleashed uses is25wp256 SPI NOR flash. There is currently no
model of this in QEMU, so to allow boot firmware developers to use QEMU
to target the Unleashed let's add a chunk of memory to represent the QSPI0
memory mapped flash. This can be targeted using QEMU's -device loader
command l
This series aims to improve the use of QEMU for developing boot code. It
does a few things:
- sifive_u machine:
- Adds a chunk of memory in the Flash area. This allows boot loaders
to use this memory. I can't find details on the QSPI flash used on
the real board, so this is the best be
Instead of using the DEFINE_MACHINE() macro to define the machine let's
do it manually. This allows us to use the machine object to create
RISCVVirtState. This is required to add children and aliases to the
machine.
This patch is no functional change.
Signed-off-by: Alistair Francis
---
hw/risc
(CCing libvir-list)
On Thu, Sep 26, 2019 at 11:58:30PM +0200, Paolo Bonzini wrote:
> Is this really needed? QEMU's value of pconfig=on vs. off should be
> provided by QMP CPU model queries, if a property is not available then
> Libvirt should not try to set it to off.
>
Libvirt can easily work a
On Thu, Sep 26, 2019 at 07:57:54PM +0100, Mark Cave-Ayland wrote:
> This patchset fixes the DFP issue reported at
> https://bugs.launchpad.net/qemu/+bug/1841990
> caused by the change in FP register storage in commit ef96e3ae96 "target/ppc:
> move FP and VMX registers into aligned vsr register arr
Richard Henderson writes:
> On 9/24/19 4:31 AM, Andrew Jones wrote:
>
>> +#if __SIZEOF_LONG__ == 8
>> +#define BIT(n) (1UL << (n))
>> +#else
>> +#define BIT(n) (1ULL << (n))
>> +#endif
>
> There's no reason not to always use 1ULL is there?
Also we already have this helper in bitops.h so shoul
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Bitmaps reopening is buggy, reopening-rw just not working at all and
> reopening-ro may lead to producing broken incremental
> backup if we do temporary snapshot in a meantime.
>
> v4: Drop complicated solution around reopen
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> The only reason I can imagine for this strange code at the very-end of
> bdrv_reopen_commit is the fact that bs->read_only updated after
> calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same
> time, prior to previous co
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> - Correct check for write access to file child, and in correct place
> (only if we want to write).
> - Support reopen rw -> rw (which will be used in following commit),
> for example, !bdrv_dirty_bitmap_readonly() is not a corruption
On 9/24/19 6:12 AM, Max Reitz wrote:
> On 07.08.19 16:12, Vladimir Sementsov-Ogievskiy wrote:
>> It's needed to fix reopening qcow2 with bitmaps to RW. Currently it
>> can't work, as qcow2 needs write access to file child, to mark bitmaps
>> in-image with IN_USE flag. But usually children goes a
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Two testcases with persistent bitmaps are not added here, as there are
> bugs to be fixed soon.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
OK:
Reviewed-by: John Snow
there may or may not be conflicts on test setup, depending on
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/iotests.py | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index ce74177ab1..4a
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Reopening bitmaps to RW was broken prior to previous commit. Check that
> it works now.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/165 | 46 --
> tests/qemu-iotest
Is this really needed? QEMU's value of pconfig=on vs. off should be
provided by QMP CPU model queries, if a property is not available then
Libvirt should not try to set it to off.
Paolo
Il gio 26 set 2019, 23:23 Eduardo Habkost ha scritto:
> QEMU 3.1.0 was shipped with the "pconfig" CPU propert
On 9/26/19 3:28 PM, Eric Blake wrote:
> On 9/26/19 1:54 PM, John Snow wrote:
>>
>>
>> On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> bdrv_dirty_bitmap_next is always used in same pattern. So, split it
>>> into _next and _first, instead of combining two functions into one and
>>> ad
On Thu, 26 Sep 2019 03:07:08 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, September 26, 2019 3:06 AM
> [...]
> > > > > The second point is about write-protection:
> > > > >
> > > > > > There is another value of recording GPA in V
On Thu, Sep 26, 2019 at 06:23:26PM -0300, Eduardo Habkost wrote:
> QEMU 3.1.0 was shipped with the "pconfig" CPU property available,
> added by commit 5131dc433df5 ("i386: Add CPUID bit for PCONFIG").
>
> Then the feature was removed in QEMU 4.0.0 (and 3.1.1), by commit
> 712f807e1965 ("Revert 'i3
QEMU 3.1.0 was shipped with the "pconfig" CPU property available,
added by commit 5131dc433df5 ("i386: Add CPUID bit for PCONFIG").
Then the feature was removed in QEMU 4.0.0 (and 3.1.1), by commit
712f807e1965 ("Revert 'i386: Add CPUID bit for PCONFIG'").
In theory this would be OK, but we do ha
This allows us to remove more endian-specific defines from int_helper.c.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/int_helper.c | 72 ++---
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
i
On Thu, 26 Sep 2019, Philippe Mathieu-Daudé wrote:
and got it almost working (boots Linux kernel to userland, sadly
I'm still having timeout issues with the eMMC block).
[...]
$ make aarch64-softmmu/all check-venv
$ ./tests/venv/bin/avocado --show=app,console run -t machine:raspi2 -t
machine:r
On Thu, Sep 26, 2019 at 10:10:53AM +0800, Tao Xu wrote:
> Add some comments, clean up comments over 80 chars per line. There
> is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD, remove
> the extra enter and spaces.
>
> Drop the duplicated definition of cpuid AVX512_VBMI macro and rename
On 9/26/19 1:54 PM, John Snow wrote:
On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
bdrv_dirty_bitmap_next is always used in same pattern. So, split it
into _next and _first, instead of combining two functions into one and
add FOR_EACH_DIRTY_BITMAP macro.
Signed-off-by: Vladimir Sem
On 9/20/19 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We need to lock qcow2 mutex on accessing in-image metadata, especially
> on updating this metadata. Let's implement it.
>
> v3:
> 01: add John's r-b
> 02: - fix bdrv_remove_persistent_dirty_bitmap return value
> - drop e
On 9/26/19 9:09 PM, Philippe Mathieu-Daudé wrote:
> On 9/26/19 8:26 PM, John Snow wrote:
>> On 9/26/19 5:57 AM, Philippe Mathieu-Daudé wrote:
>>> Hi Sam,
>>>
>>> On 9/25/19 1:06 PM, Sam Eiderman wrote:
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to
Alistair Francis writes:
> On Thu, Sep 26, 2019 at 8:41 AM Alex Bennée wrote:
>>
>>
>> Thomas Huth writes:
>>
>> > On 26/09/2019 15.46, Christian Borntraeger wrote:
>> >>
>> >>
>> >> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>> >>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, Peter Maydell wr
On 9/24/19 4:31 AM, Andrew Jones wrote:
> +static uint32_t sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
> +{
> +uint32_t start_vq = (start_len & 0xf) + 1;
> +
> +return arm_cpu_vq_map_next_smaller(cpu, start_vq + 1) - 1;
> +}
> +
> /*
> * Given that SVE is enabled, return the v
1 - 100 of 390 matches
Mail list logo
