Am 18.02.2020 um 06:07 hat Coiby Xu geschrieben:
> Sharing QEMU devices via vhost-user protocol
>
> Signed-off-by: Coiby Xu
> ---
> util/Makefile.objs | 3 +
> util/vhost-user-server.c | 427 +++
> util/vhost-user-server.h | 56 +
> 3 files change
On 2/25/20 9:32 AM, Eduardo Habkost wrote:
> On Mon, Feb 24, 2020 at 05:13:18PM -0600, Babu Moger wrote:
>>
>>
>> On 2/24/20 4:31 PM, Eduardo Habkost wrote:
>>> On Mon, Feb 24, 2020 at 11:58:09AM -0600, Babu Moger wrote:
On 2/24/20 11:19 AM, Igor Mammedov wrote:
> On Thu, 13 F
On Tue, 25 Feb 2020 10:37:14 +1100
David Gibson wrote:
> When we store the Logical Partitioning Control Register (LPCR) we have a
> big switch statement to work out which are valid bits for the cpu model
> we're emulating.
>
> As well as being ugly, this isn't really conceptually correct, since
@options is leaked by the first two return statements in this function.
Note that blk_new_open() takes the reference to @options even on
failure, so all we need to do to fix the leak is to move the QDict
allocation down to where we actually need it.
Reported-by: Coverity (CID 1419884)
Fixes: fd17
On 2/25/20 5:24 AM, Peter Maydell wrote:
> This check is supposed to be "did the user accidentally specify
> some incompatible settings on their '-cpu,+this,-that' option?".
> By making it check the actual ID register values, you're turning
> it into also a check on "does the implementation specify
On Tue, 25 Feb 2020 12:29:00 +0100
Greg Kurz wrote:
> On Tue, 25 Feb 2020 10:37:12 +1100
> David Gibson wrote:
>
> > For the "pseries" machine, we use "virtual hypervisor" mode where we
> > only model the CPU in non-hypervisor privileged mode. This means that
> > we need guest physical address
On Tue, 25 Feb 2020 at 15:55, Richard Henderson
wrote:
>
> On 2/25/20 5:24 AM, Peter Maydell wrote:
> > This check is supposed to be "did the user accidentally specify
> > some incompatible settings on their '-cpu,+this,-that' option?".
> > By making it check the actual ID register values, you're
On 2/25/20 7:58 AM, Peter Maydell wrote:
>> Do you want me to add a tcg_enabled check, or shall we just drop the patch?
>> The existing test is good enough for just checking the command-line.
>
> If it isn't a requirement for the rest of the series, let's just
> drop the patch.
It isn't; there sh
On Thu, Dec 19, 2019 at 07:10:24PM +0100, Juan Quintela wrote:
> Anthony PERARD wrote:
> > It is possible that a ramblock doesn't have memory that QEMU can
> > access, this is the case with the Xen hypervisor.
> >
> > In order to avoid to trigger an assert, only call ramblock_ptr() when
> > needed
25.02.2020 3:56, John Snow wrote:
This job copies the allocation map into a bitmap. It's a job because
there's no guarantee that allocation interrogation will be quick (or
won't hang), so it cannot be retrofit into block-dirty-bitmap-merge.
It was designed with different possible population patt
Dear KVM list members,
We developed a virtual machine using the QEMU code. This virtual
machine emulates a certain custom-made computer that runs on a certain
military platform. All I can tell you about this virtual machine is
that it emulates a computer that has an e5500 processor. Currently I
Am 18.02.2020 um 06:07 hat Coiby Xu geschrieben:
> By making use of libvhost, multiple block device drives can be exported
> and each drive can serve multiple clients simultaneously.
> Since vhost-user-server needs a block drive to be created first, delay
> the creation of this object.
>
> Signed-
On Fri, Feb 21, 2020 at 05:42:01PM +0100, David Hildenbrand wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> In the case of postcopy,
On Tue, Feb 25, 2020 at 2:02 AM Philippe Mathieu-Daudé
wrote:
>
> On 2/24/20 10:20 PM, Alistair Francis wrote:
> > On Mon, Feb 24, 2020 at 12:51 PM Philippe Mathieu-Daudé
> > wrote:
> >>
> >> This commit was produced with the Coccinelle script
> >> scripts/coccinelle/memory-region-housekeeping.co
On 20.02.20 13:10, Vladimir Sementsov-Ogievskiy wrote:
> 20.02.2020 14:58, Max Reitz wrote:
>> On 14.01.20 09:22, Andrey Shinkevich wrote:
>>> The information about QCOW2 metadata allocations in an image ELF-file is
>>> helpful for finding issues with the image data integrity.
>>
>> Sorry that I’m
On Tue, 25 Feb 2020 at 16:10, Wayne Li wrote:
> So what could be causing this problem? I’m guessing it has something
> to do with the translation lookaside buffers (TLBs)? But the
> translation between virtual and physical memory clearly works when KVM
> isn’t enabled. So what could cause this
On Tue, Feb 25, 2020 at 5:23 AM Damien Hedde wrote:
>
> This object may be used to represent a clock inside a clock tree.
>
> A clock may be connected to another clock so that it receives update,
> through a callback, whenever the source/parent clock is updated.
>
> Although only the root clock of
On 21.02.20 12:25, Stefan Hajnoczi wrote:
> v4:
> * This revision is what German speakers call "das Tüpfelchen auf dem I".
> "The
>icing on the cake" is the English equivalent. Since I like cake and don't
>want it to be half-baked, and because I like my metaphors shaken, not
>stirre
On Tue, Feb 25, 2020 at 6:01 AM Damien Hedde wrote:
>
> Add functions to easily handle clocks with devices.
> Clock inputs and outputs should be used to handle clock propagation
> between devices.
> The API is very similar the GPIO API.
>
> This is based on the original work of Frederic Konrad.
>
The MIPS CPU models end up in the middle of the PC documentation. Move
them to a separate file so that they can be placed in the right section.
The man page still includes both x86 and MIPS content.
Signed-off-by: Paolo Bonzini
---
Makefile | 11 +-
docs/s
This section covers OSes up to Windows 2000, and as such it is mostly
obsolete. Zap it.
Signed-off-by: Paolo Bonzini
---
qemu-doc.texi | 96 ---
1 file changed, 96 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 33b9597b1d..56d3e57c
Prior to rST conversion, reorganize qemu-doc so that PC is handled
like all other targets and there is a generic "system emulation"
chapter.
This conflicts with the docs/system/cpu-models.texi conversion to
rST, but I would like to have a review for the third and fourth
patch while that conversion
Move the section on PC peripherals together with other targets.
While some x86-specific information remains in the main system
emulation chapter, it can be tackled more easily a section at a
time.
Signed-off-by: Paolo Bonzini
---
docs/system/quickstart.texi | 2 +-
qemu-doc.texi
In order to facilitate the reorganization of qemu-doc.texi content,
as well as the conversion to rST/Sphinx, split it in multiple .texi
files that are included from docs/system.
Signed-off-by: Paolo Bonzini
---
docs/system/gdb.texi | 71 ++
docs/system/images.texi | 88 +++
do
On Tue, 25 Feb 2020 at 15:12, Michael S. Tsirkin wrote:
>
> The following changes since commit 9a8abceb5f01d1066d3a1ac5a33aabcbaeec1860:
>
> Merge remote-tracking branch 'remotes/pmaydell/tags/pull-docs-20200225'
> into staging (2020-02-25 11:03:47 +)
>
Max Reitz writes:
> On 15.02.20 15:51, Markus Armbruster wrote:
>> Review of this patch led to a lengthy QAPI schema design discussion.
>> Let me try to condense it into a concrete proposal.
>>
>> This is about the QAPI schema, and therefore about QMP. The
>> human-friendly interface is out of
On 05.12.19 15:04, Eric Blake wrote:
> On 12/5/19 3:42 AM, Stefano Garzarella wrote:
>> Hi Pan,
>>
>> On Thu, Dec 05, 2019 at 11:45:27AM +0800, pannengy...@huawei.com wrote:
>>> From: Pan Nengyuan
>>>
>>> The BDRVNBDState cleanup code is common in two places, add
>>> nbd_clear_bdrvstate() function
On 25/02/20 17:02, Anthony PERARD wrote:
> On Thu, Dec 19, 2019 at 07:10:24PM +0100, Juan Quintela wrote:
>> Anthony PERARD wrote:
>>> It is possible that a ramblock doesn't have memory that QEMU can
>>> access, this is the case with the Xen hypervisor.
>>>
>>> In order to avoid to trigger an asse
On Tue, 25 Feb 2020 at 16:38, Paolo Bonzini wrote:
>
> This section covers OSes up to Windows 2000, and as such it is mostly
> obsolete. Zap it.
>
> Signed-off-by: Paolo Bonzini
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
In v4:
- Correctly use the 'define-man-page' rule for qemu-cpu-models.7
[pm215]
- Fix author attribution as per the thread:
Message-ID:
[danpb, pm215]
- Don't reverse the existing order of the list of CPU models [pm215]
- Use rST "definition lists" consistently throughout the docum
- Add the '-noTSX' variants for CascadeLake and SkyLake.
- Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl'
Two confusing things about 'mds-no' (and the first point applies to
the other two MSRs too):
(1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo.
This doc was originally written by Daniel P. Berrangé
, introduced via commit[1]: 2544e9e4aa (docs: add
guidance on configuring CPU models for x86, 2018-06-27).
In this patch:
- 1-1 conversion of Texinfo to rST, besides a couple of minor
tweaks that are too trivial to mention. (Thanks to
On Mon, 17 Feb 2020 21:12:46 +0800
Dongjiu Geng wrote:
> kvm_arch_on_sigbus_vcpu() error injection uses source_id as
> index in etc/hardware_errors to find out Error Status Data
> Block entry corresponding to error source. So supported source_id
> values should be assigned here and not be changed
On Mon, 24 Feb 2020 16:37:44 +0800
gengdongjiu wrote:
> On 2020/2/21 22:09, Peter Maydell wrote:
> > On Mon, 17 Feb 2020 at 13:10, Dongjiu Geng wrote:
> >>
> >> In the ARMv8 platform, the CPU error types includes synchronous external
> >> abort(SEA) and SError Interrupt (SEI). If exception ha
On 25.02.20 17:48, Markus Armbruster wrote:
> Max Reitz writes:
>
>> On 15.02.20 15:51, Markus Armbruster wrote:
>>> Review of this patch led to a lengthy QAPI schema design discussion.
>>> Let me try to condense it into a concrete proposal.
>>>
>>> This is about the QAPI schema, and therefore ab
On 25/02/20 16:41, Peter Maydell wrote:
> This patchset converts some texi files used in qemu-doc.texi to rST:
>
> * docs/security.texi
> * qemu-tech.texi
> * qemu-deprecated.texi
>
> which all end up as sections of the "system" manual.
>
> In all cases, these pieces of the documentation are
On Tue, 25 Feb 2020 10:37:15 +1100
David Gibson wrote:
> Currently we use a big switch statement in ppc_hash64_update_rmls() to work
> out what the right RMA limit is based on the LPCR[RMLS] field. There's no
> formula for this - it's just an arbitrary mapping defined by the existing
> CPU imple
On Fri, 1 Feb 2019 at 16:07, Peter Maydell wrote:
>
> From: Aaron Lindsay OS
>
> Whenever we notice that a counter overflow has occurred, send an
> interrupt. This is made more reliable with the addition of a timer in a
> follow-on commit.
>
> Signed-off-by: Aaron Lindsay
> Reviewed-by: Richard
On Tue, 25 Feb 2020 at 17:01, Paolo Bonzini wrote:
>
> On 25/02/20 16:41, Peter Maydell wrote:
> > This patchset converts some texi files used in qemu-doc.texi to rST:
> >
> > * docs/security.texi
> > * qemu-tech.texi
> > * qemu-deprecated.texi
> >
> > which all end up as sections of the "syste
On 24.02.20 11:13, David Edmondson wrote:
> RFC 7230 section 3.2 indicates that whitespace is permitted between
> the field name and field value and after the field value.
>
> Signed-off-by: David Edmondson
> ---
> block/curl.c | 31 +++
> 1 file changed, 27 insertion
On 24.02.20 11:13, David Edmondson wrote:
> RFC 7230 section 3.2 indicates that HTTP header field names are case
> insensitive.
>
> Signed-off-by: David Edmondson
> ---
> block/curl.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Max Reitz
signature.asc
Descripti
On 24.02.20 11:13, David Edmondson wrote:
> An HTTP object store of my acquaintance returns "accept-ranges: bytes"
> (all lower case) as a header, causing the QEMU curl backend to refuse
> to talk to it. RFC 7230 says that HTTP headers are case insensitive,
> so update the curl backend accordingly.
On Tue, Feb 25, 2020 at 05:48:02PM +0100, Markus Armbruster wrote:
> Max Reitz writes:
>
> > On 15.02.20 15:51, Markus Armbruster wrote:
> >> Review of this patch led to a lengthy QAPI schema design discussion.
> >> Let me try to condense it into a concrete proposal.
> >>
> >> This is about the
This series collects patches adding tests for arm machines.
All patches are reviewed.
Philippe Mathieu-Daudé (2):
tests/acceptance: Extract boot_integratorcp() from test_integratorcp()
tests/acceptance/integratorcp: Verify Tux is displayed on framebuffer
Thomas Huth (2):
tests/acceptance: A
From: Thomas Huth
Old kernels from the Meego project can be used to check that Linux
is at least starting on these machines.
Signed-off-by: Thomas Huth
Reviewed-by: Wainer dos Santos Moschetta
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20200129131920.2
From: Thomas Huth
There is a kernel and initrd available on github which we can use
for testing this machine.
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Wainer dos Santos Moschetta
Message-Id: <20200131170233.14584-1-th...@re
From: Philippe Mathieu-Daudé
Add a test that verifies the Tux logo is displayed on the framebuffer.
We simply follow the OpenCV "Template Matching with Multiple Objects"
tutorial, replacing Lionel Messi by Tux:
https://docs.opencv.org/4.2.0/d4/dc6/tutorial_py_template_matching.html
When OpenCV
From: Philippe Mathieu-Daudé
As we want to re-use this code, extract it as a new function.
Since we are using the PL011 serial console, add a Avocado tag
to ease filtering of tests.
Reviewed-by: Thomas Huth
Reviewed-by: Wainer dos Santos Moschetta
Signed-off-by: Philippe Mathieu-Daudé
---
te
On Mon, 24 Feb 2020 at 22:22, Richard Henderson
wrote:
>
> The main goal of the patchset is to move the ARM_FEATURE_VFP test from
> outside of the disas_vfp_insn() to inside each of the trans_* functions,
> so that we get the proper ISA check for each case. At the end of that,
> it is easy to eli
On 19.02.20 15:41, Eric Blake wrote:
> Tests 261 and 272 fail on RHEL 7 with coreutils 8.22, since od
> --endian was not added until coreutils 8.23. Fix this by manually
> constructing the final value one byte at a time.
>
> Fixes: fc8ba423
> Reported-by: Andrey Shinkevich
> Signed-off-by: Eric
On 2/25/20 4:01 AM, Peter Maydell wrote:
> The set of operations this traps differs when ARMv8.4-TLBI is
> implemented. It looks like you've applied this access fn to
> the wider with-v8.4-TLBI set? (eg TLBI_VMALLE1 is only trapped
> with ARMv8.4-TLBI, not without.)
Um, that's not true.
ARMv8.4-T
On 25/02/20 18:11, Peter Maydell wrote:
>> I assume these are not meant to be applied now, except patch 2?
> No, I intended them to be reviewable and applied now. Why
> do you think we should wait?
Because they remove information from qemu-doc.texi. I think it's
feasible to do a mass conversion q
On Tue, 25 Feb 2020 at 17:46, Richard Henderson
wrote:
>
> On 2/25/20 4:01 AM, Peter Maydell wrote:
> > The set of operations this traps differs when ARMv8.4-TLBI is
> > implemented. It looks like you've applied this access fn to
> > the wider with-v8.4-TLBI set? (eg TLBI_VMALLE1 is only trapped
>
On 02/24/20 16:28, Daniel P. Berrangé wrote:
> On Tue, Feb 11, 2020 at 05:39:59PM +, Alex Bennée wrote:
>>
>> wuchenye1995 writes:
>>
>>> Hi all,
>>>We found a problem with live migration of UEFI virtual machines
>>>due to size of OVMF.fd changes.
>>>Specifically, the size of OVMF.
On Tue, 25 Feb 2020 at 17:48, Paolo Bonzini wrote:
>
> On 25/02/20 18:11, Peter Maydell wrote:
> >> I assume these are not meant to be applied now, except patch 2?
> > No, I intended them to be reviewable and applied now. Why
> > do you think we should wait?
>
> Because they remove information fro
Changes for v4:
* Mask more res0 bits for HCR.
* Fixes for TVM/TRVM.
* Fixes for el0 for TPCP & TPU.
r~
Richard Henderson (7):
target/arm: Improve masking of HCR RES0 bits
target/arm: Honor the HCR_EL2.{TVM,TRVM} bits
target/arm: Honor the HCR_EL2.TSW bit
target/arm: Honor the HCR_E
These bits trap EL1 access to set/way cache maintenance insns.
Buglink: https://bugs.launchpad.net/bugs/1863685
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/target/
Don't merely start with v8.0, handle v7VE as well.
Notice writes from aarch32 mode, and the bits that
ought not be settable from there.
Suggested-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
These bits trap EL1 access to various virtual memory controls.
Buglink: https://bugs.launchpad.net/bugs/1855072
Signed-off-by: Richard Henderson
---
v2: Include TTBCR.
v4: Include not_v8_cp_reginfo, lpae_cp_reginfo, CONTEXTIDR_S;
exclude not_v7_cp_reginfo (pmm).
---
target/arm/helper.c | 82
This bit traps EL1 access to the auxiliary control registers.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index ea42e0d26d..5
This bit traps EL1 access to cache maintenance insns that operate
to the point of coherency or persistence.
Signed-off-by: Richard Henderson
---
v4: Fix el0 fallthru (pmm).
---
target/arm/helper.c | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
dif
This bit traps EL1 access to cache maintenance insns that operate
to the point of unification. There are no longer any references to
plain aa64_cacheop_access, so remove it.
Signed-off-by: Richard Henderson
---
v4: Fix el0 fallthru (pmm).
---
target/arm/helper.c | 53 +++
This bit traps EL1 access to tlb maintenance insns.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 85 +
1 file changed, 55 insertions(+), 30 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index ca67d6a770..20688d1a18
On 2/25/20 7:46 AM, Alex Bennée wrote:
At least on ZFS this was failing as 512 was less than or equal to 512.
I suspect the reason is additional compression done by ZFS and however
qemu-img gets the actual size.
Loosen the criteria to make sure after is not bigger than before and
also dump the v
In our KVM GICv2 realize function, we try to cope with old kernels
that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we
try to use the device control, and if that fails we fall back to
assuming that the kernel has the old style KVM_CREATE_IRQCHIP and
that it will provide a GICv2.
Th
On 25/02/20 18:59, Peter Maydell wrote:
> My assumption was that we would attack this by:
> * converting chunks of the documentation which are in qemu-doc.texi
>but which aren't in the qemu.1 manpage (basically in the way this
>series is doing)
> * get the qapidoc generation conversion re
On Tue, Feb 25, 2020 at 04:47:31PM +, Peter Maydell wrote:
> On Tue, 25 Feb 2020 at 15:12, Michael S. Tsirkin wrote:
> >
> > The following changes since commit 9a8abceb5f01d1066d3a1ac5a33aabcbaeec1860:
> >
> > Merge remote-tracking branch 'remotes/pmaydell/ta
On 2/25/20 7:22 PM, Stefan Berger wrote:
On 2/25/20 7:46 AM, Alex Bennée wrote:
At least on ZFS this was failing as 512 was less than or equal to 512.
I suspect the reason is additional compression done by ZFS and however
qemu-img gets the actual size.
Loosen the criteria to make sure after is
On 2/25/20 7:24 PM, Peter Maydell wrote:
In our KVM GICv2 realize function, we try to cope with old kernels
that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we
try to use the device control, and if that fails we fall back to
assuming that the kernel has the old style KVM_CREATE_IR
On 25/02/20 17:56, Kashyap Chamarthy wrote:
> In v4:
> - Correctly use the 'define-man-page' rule for qemu-cpu-models.7
>[pm215]
> - Fix author attribution as per the thread:
>Message-ID:
>
>[danpb, pm215]
> - Don't reverse the existing order of the list of CPU models [pm215]
>
On Tue, 25 Feb 2020 at 18:28, Paolo Bonzini wrote:
>
> On 25/02/20 18:59, Peter Maydell wrote:
> > My assumption was that we would attack this by:
> > * converting chunks of the documentation which are in qemu-doc.texi
> >but which aren't in the qemu.1 manpage (basically in the way this
> >
Laszlo,
If I understand this correctly is it not more complicated than just size. It
also assumes the memory layout is the same? The legacy BIOS used fixed magic
address ranges, but UEFI uses dynamically allocated memory so addresses are not
fixed. While the UEFI firmware does try to keep S3 an
Il mar 25 feb 2020, 19:57 Peter Maydell ha
scritto:
> > The QAPI docs are in other manuals in docs/interop/, aren't they?
>
> Yes, but until we complete the conversion we can't get
> rid of the qemu-doc.html output, because that's where the
> HTML output from the QAPI doc generation goes.
>
Righ
Some experimentation with newer kernels indicate that this is most
likely a KVM bug.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1863819
Title:
The ARMv8.2-TTCNP extension allows an implementation to optimize by
sharing TLB entries between multiple cores, provided that software
declares that it's ready to deal with this by setting a CnP bit in
the TTBRn_ELx. It is mandatory from ARMv8.2 onward.
For QEMU's TLB implementation, sharing TLB
On Tue, 25 Feb 2020 at 19:10, Paolo Bonzini wrote:
> This could go in independently. It would make Kashyap's series
> conflict, but I have already rebased it on top.
I'm happy to collect up 'docs' patches for pullreqs (and fix up
conflicts etc as they arise) if that helps in getting things into
t
On 2/25/20 11:38 AM, Peter Maydell wrote:
> @@ -705,6 +706,7 @@ static void aarch64_max_initfn(Object *obj)
>
> u = cpu->isar.id_mmfr4;
> u = FIELD_DP32(u, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */
> +t = FIELD_DP32(t, ID_MMFR4, CNP, 1); /* TTCNP */
> cpu->isar.i
On 2/12/20 7:22 PM, Richard Henderson wrote:
> Changes for v3:
>
> * Add TARGET_VSYSCALL_PAGE define.
> * Move the sigsegv goto around.
>
> v2: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03474.html
> v1: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02841.html
Ping?
Il mar 25 feb 2020, 20:50 Peter Maydell ha
scritto:
> On Tue, 25 Feb 2020 at 19:10, Paolo Bonzini wrote:
> I feel like we're working a bit at cross purposes here so maybe
> we'd benefit from just nailing down who's going to do what and
> in which order?
>
I am not going to do much more than wha
Public bug reported:
Hi,
I'm trying to use qemu-system-ppc64 for emulating a QorIQ T2080 (with e6500
cores).
However, I couldn't find any -machine option that matches -cpu e6500 option,
which are listed below:
C:\Program Files\qemu>qemu-system-ppc64 -machine help
Supported machines are:
40p
Peter Maydell writes:
> Add patterns for the new instructions in the v8.3-RCPC and
> v8.4-RCPC extensions.
>
> Signed-off-by: Peter Maydell
> ---
> This is what I used for testing the RCPC QEMU patches I sent out
> the other day. Did I get the @ section syntax here right?
Yep ;-)
Reviewed-by
Hi Andrew,
On 02/25/20 19:56, Andrew Fish wrote:
> Laszlo,
>
> If I understand this correctly is it not more complicated than just size. It
> also assumes the memory layout is the same?
Yes.
> The legacy BIOS used fixed magic address ranges, but UEFI uses dynamically
> allocated memory so add
On 2/25/20 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
> 25.02.2020 3:56, John Snow wrote:
>> This job copies the allocation map into a bitmap. It's a job because
>> there's no guarantee that allocation interrogation will be quick (or
>> won't hang), so it cannot be retrofit into block-dirty-b
Le 25/02/2020 à 20:59, Richard Henderson a écrit :
> On 2/12/20 7:22 PM, Richard Henderson wrote:
>> Changes for v3:
>>
>> * Add TARGET_VSYSCALL_PAGE define.
>> * Move the sigsegv goto around.
>>
>> v2: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03474.html
>> v1: https://lists.gnu
Hello,
On Mon, 10 Feb 2020, John Snow wrote:
It sounds like the real problem is either in the bmdma controller (or
its unique interaction with hw/ide/core.c -- which is possible) or in
the interrupt routing somewhere else.
If you have any IDE traces from a hang, feel free to throw them up on a
Hi,
I need the memory access traces of an android system running on qemu.
trace_memory_region_ops_read/write in memory.c provide most of the
information I need. However, in addition to the trace information already
provided, I also need the program counter of the current instructions. What
changes
> On Feb 25, 2020, at 12:40 PM, Laszlo Ersek wrote:
>
> Hi Andrew,
>
> On 02/25/20 19:56, Andrew Fish wrote:
>> Laszlo,
>>
>> If I understand this correctly is it not more complicated than just size. It
>> also assumes the memory layout is the same?
>
> Yes.
>
>> The legacy BIOS used fixe
On 2/24/20 9:09 PM, kuhn.chen...@huawei.com wrote:
> From: Chen Qun
>
> Clang static code analyzer show warning:
> block/stream.c:186:9: warning: Value stored to 'ret' is never read
> ret = 0;
> ^ ~
> Reported-by: Euler Robot
> Signed-off-by: Chen Qun
> ---
> Cc: John S
On 2/24/20 6:15 AM, Max Reitz wrote:
> On 12.10.19 01:39, John Snow wrote:
>> Just caught up with the discussion.
>>
>> It looks like Thomas took my 1/5; so I'll respin on top of his "[PATCH
>> 0/5] Enable more iotests during "make check-block" series to catch those
>> improvements as they stand
On 2/18/20 5:07 AM, Fabian Grünbichler wrote:
> picking up on John's in-progress patch series from last summer, this is
> a stab at rebasing and adding test cases for the low-hanging fruits:
>
> - bitmap mirror mode with always/on-success/never bitmap sync mode
> - incremental mirror mode as su
On Tue, Feb 25, 2020 at 04:47:31PM +, Peter Maydell wrote:
> On Tue, 25 Feb 2020 at 15:12, Michael S. Tsirkin wrote:
> >
> > The following changes since commit 9a8abceb5f01d1066d3a1ac5a33aabcbaeec1860:
> >
> > Merge remote-tracking branch 'remotes/pmaydell/ta
On Tue, 25 Feb 2020, BALATON Zoltan wrote:
On Mon, 10 Feb 2020, John Snow wrote:
It sounds like the real problem is either in the bmdma controller (or
its unique interaction with hw/ide/core.c -- which is possible) or in
the interrupt routing somewhere else.
If you have any IDE traces from a ha
On Mon, 10 Feb 2020, BALATON Zoltan wrote:
This suggests the common IDE bmdma and ide-cd code is likely OK and problem
is somewhere in irq routing. What's relevant for this thread and sparc64 is
that then you should also check interrupt controller and routing if an
interrupt raised by the IDE c
On Tue, 25 Feb 2020 at 20:10, Paolo Bonzini wrote:
> The main issue with this series and Kashyap's is that if we don't manage to
> get
> everything done in 5.0 we have a mutilated qemu-doc. Then either we keep it
> mutilated or we scramble to undo the work. So I would agree to commit the
> series
On Tue, 25 Feb 2020 18:05:31 +0100
Greg Kurz wrote:
> On Tue, 25 Feb 2020 10:37:15 +1100
> David Gibson wrote:
>
> > Currently we use a big switch statement in ppc_hash64_update_rmls() to work
> > out what the right RMA limit is based on the LPCR[RMLS] field. There's no
> > formula for this -
Hello Igor and Paolo,
Just now I was working on some small fixes for the cubieboard machine and
rebasing my Allwinner H3 branches.
While doing some testing, I noticed that suddenly the machines were much
slower than before.
I only see this happening when I rebase to this commit:
ca6155c0f2bd39b
To compute screen size in centimeters we should calculate:
pixels/dpi*2.54
but not
pixels*dpi/2540
Using wrong formula we actually get 65 DPI and very small fonts.
Signed-off-by: Anton V. Boyarshinov
---
hw/display/edid-generate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
[ ping ]
Hi Paolo, would you mind taking a quick look at this patch for
memory.c to consider
it for merge? This resolves an issue with dirty bits not being cleared
as expected.
Here's the Patchwork link: http://patchwork.ozlabs.org/patch/1240121/
Thanks for your time!
Matt
On Tue, Feb 18, 2020
Try "-M ppce500 -cpu e6500"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1864704
Title:
No compatible -machine option in qemu-system-ppc64 for e6500 core
Status in QEMU:
New
Bug description:
On 21/02/2020 19:27, Paolo Bonzini wrote:
> On 21/02/20 01:18, Alexey Kardashevskiy wrote:
>> I am not quite sure I understood the request. Write my own small
>> firmware and replace GRUB with it? The firmware from 5/5 reads first 2
>> sectors and the entire PReP, I could add there stuff if tha
401 - 500 of 551 matches
Mail list logo
