On Fri, Jan 3, 2020 at 11:43 AM Philippe Mathieu-Daudé
wrote:
>
> On 1/3/20 8:39 AM, Marc-André Lureau wrote:
> > Signed-off-by: Marc-André Lureau
> > ---
> > exec.c| 4 ++--
> > roms/SLOF | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/exec.c b/exec.c
>
The Petitboot bootloader is way more advanced than SLOF is ever going to
be as Petitboot comes with the full-featured Linux kernel with all
the drivers, and initramdisk with quite user friendly interface.
The problem with ditching SLOF is that an unmodified pseries kernel can
either start via:
1.
On 1/3/20 8:40 AM, Marc-André Lureau wrote:
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
---
migration/savevm.c | 5 +
1 file changed, 5
On 1/3/20 8:39 AM, Marc-André Lureau wrote:
Signed-off-by: Marc-André Lureau
---
exec.c| 4 ++--
roms/SLOF | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index d4b769d0d4..1feda49ca1 100644
--- a/exec.c
+++ b/exec.c
@@ -3895,7 +3895,7 @@ int
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..bbb7e89682
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
exec.c| 4 ++--
roms/SLOF | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index d4b769d0d4..1feda49ca1 100644
--- a/exec.c
+++ b/exec.c
@@ -3895,7 +3895,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start,
Hi,
The following series fixes a migration issue with the TPM PPI code due
to unaligned host RAM pointer.
v2:
- use QEMU_IS_ALIGNED macros
- remove RFC status from "savevm: check RAM is pagesize aligned"
Marc-André Lureau (3):
misc: use QEMU_IS_ALIGNED
tpm-ppi: page-align PPI RAM
savevm:
Ignore this please, v2 is coming soon. And this one is missing "RFC"
anyway. Thanks,
On 03/01/2020 17:12, Alexey Kardashevskiy wrote:
> The Petitboot bootloader is way more advanced than SLOF is ever going to
> be as Petitboot comes with the full-featured Linux kernel with all
> the drivers,
Hi Richard,
On 10/15/19 7:51 PM, Richard Henderson wrote:
Tested vs centos7, fedora30, and bionic (with and without
system capstone installed).
Change noted while testing:
* Raw byte dumped as hexa
before: no
after: dumped by 16-bit
OK
* Address format
before: "0x" TARGET_FMT_lx
Patchew URL: https://patchew.org/QEMU/20200103061217.16396-1-...@ozlabs.ru/
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 BEGIN ===
When running guests under a hypervisor, the hypervisor obviously needs to
be protected from guest accesses even if those are in what the guest
considers real mode (translation off). The POWER hardware provides two
ways of doing that: The old way has guest real mode accesses simply offset
and
The only effect of the PPC_EMULATE_32BITS_HYPV define is to change how
MSR_HVB is defined. This appears to be something to handle hypervisor mode
for 32-bit CPUs, but there's really no other code to handle this. The
MSR_THV bit, which it uses is implemented for no cpus we model.
It's unlikely
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode,
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability.
However, it can be (and often was) strapped into "Apple mode", where the
hypervisor capabilities were disabled (essentially putting it always in
hypervisor mode).
That's actually the only mode of the 970 we support in
POWER "book S" (server class) cpus have a concept of "real mode" where
MMU translation is disabled... sort of. In fact this can mean a bunch
of slightly different things when hypervisor mode and other
considerations are present.
We had some errors in edge cases here, so clean some things up and
Hi
On Fri, Jan 3, 2020 at 9:06 AM Philippe Mathieu-Daudé wrote:
>
> Hi Marc-André,
>
> On 1/2/20 10:01 PM, Marc-André Lureau wrote:
> > Check the host pointer is correctly aligned, otherwise we may fail
> > during migration in ram_block_discard_range().
> >
> > Signed-off-by: Marc-André Lureau
Hi Richard,
On 12/29/19 12:11 AM, Richard Henderson wrote:
Code movement in an upcoming patch will show that this file
was implicitly depending on trace/mem.h being included beforehand.
Ah, it uses the TRACE_MEM_* macros from "trace/mem-internal.h", which is
include by "trace/mem.h". OK.
Hi Sven,
On 12/20/19 10:15 PM, Sven Schnelle wrote:
Signed-off-by: Sven Schnelle
---
hw/hppa/Kconfig| 1 +
hw/hppa/lasi.c | 10 +-
hw/input/Kconfig | 3 +
hw/input/Makefile.objs | 1 +
hw/input/lasips2.c | 289
The Petitboot bootloader is way more advanced than SLOF is ever going to
be as Petitboot comes with the full-featured Linux kernel with all
the drivers, and initramdisk with quite user friendly interface.
The problem with ditching SLOF is that an unmodified pseries kernel can
either start via:
1.
Hope you enjoyed the Holidays, Happy 2020! I would really appreciate if you
could confirm for me if virtio works fine for you with ppc -M mpc8544ds with
older Linux guest kernels like 2.6.32
thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
On 1/2/20 10:01 PM, Marc-André Lureau wrote:
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc:
Thanks Philippe & Gred. I would start with the below pointers.
Regards,
Sai Pavan
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: Thursday, January 2, 2020 4:56 PM
> To: kra...@redhat.com; Sai Pavan Boddu
> Cc: peter.mayd...@linaro.org; qemu-devel@nongnu.org
> Subject: Re:
Hi Marc-André,
On 1/2/20 10:01 PM, Marc-André Lureau wrote:
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git
Until v0.7.1 specification, vector status is still not defined for
mstatus.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu_bits.h | 15 +++
target/riscv/csr.c | 92 +
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git
Vector extension is default on only for "any" cpu. It can be turned
on by command line "-cpu rv64,vlen=128,elen=64,vext_spec=v0.7.1".
vlen is the vector register length, default value is 128 bit.
elen is the max operator size in bits, default value is 64 bit.
vext_spec is the vector specification
vsetvl and vsetvli are two configure instructions for vl, vtype. TB flags
should update after configure instructions. The (ill, lmul, sew ) of vtype
and the bit of (VSTART == 0 && VL == VLMAX) will be placed within tb_flags.
Signed-off-by: LIU Zhiwei
---
target/riscv/Makefile.objs
The 32 vector registers will be viewed as a continuous memory block.
It avoids the convension between element index and (regno,offset).
Thus elements can be directly accessed by offset from the first vector
base address.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu.h | 14 ++
1
This is the first part of v3 patchset. The changelog of v3 is only coverd
the part1.
Features:
* support specification riscv-v-spec-0.7.1.
* support basic vector extension.
* support Zvlsseg.
On Wed, Jan 1, 2020 at 3:25 AM Philippe Mathieu-Daudé wrote:
>
> All tcg includes are relative to the repository root directory,
> we can safely remove the tcg/ directory from the include search
> path list.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
>
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> All the *.inc.c files included by tcg/$TARGET/tcg-target.inc.c
> are in tcg/, their parent directory. To simplify the preprocessor
> search path, include the relative parent path: '..'.
>
> Patch created mechanically by running:
>
>
On Wed, Jan 1, 2020 at 3:27 AM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> {tcg => include/tcg}/tcg-gvec-desc.h | 0
> {tcg => include/tcg}/tcg-mo.h| 0
> {tcg => include/tcg}/tcg-op-gvec.h | 0
> {tcg =>
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> We currently search both the root and the tcg/ directories for tcg
> files:
>
> $ git grep '#include "tcg/' | wc -l
> 28
>
> $ git grep '#include "tcg[^/]' | wc -l
> 94
>
> To simplify the preprocessor search path, unify by
On Thu, Jan 02, 2020 at 01:21:10PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch includes migration support for machine check
> handling. Especially this patch blocks VM migration
> requests until the machine check error handling is
> complete as these errors are specific to
On Tue, Dec 17, 2019 at 02:49:36AM -0600, Shivaprasad G Bhat wrote:
> This patch implements few of the necessary hcalls for the nvdimm support.
>
> PAPR semantics is such that each NVDIMM device is comprising of multiple
> SCM(Storage Class Memory) blocks. The guest requests the hypervisor to
>
On Thu, Jan 02, 2020 at 01:21:09PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch adds support in QEMU to handle "ibm,nmi-register"
> and "ibm,nmi-interlock" RTAS calls.
>
> The machine check notification address is saved when the
> OS issues "ibm,nmi-register" RTAS call.
>
On Tue, Dec 17, 2019 at 02:49:14AM -0600, Shivaprasad G Bhat wrote:
> Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
> device interface in QEMU to support virtual NVDIMM devices for Power.
> Create the required DT entries for the device (some entries have
> dummy values
On Thu, Jan 2, 2020 at 10:18 AM Palmer Dabbelt wrote:
>
> On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
> > The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
> > Now that we don't use atomics for MIP we can change this back to a xlen
> > CSR.
> >
> >
On 1/1/20 10:22 PM, Philippe Mathieu-Daudé wrote:
> Noticed we could clean this while reviewing Richard patch last night:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg667606.html
>
> Since v1:
> - moved headers to include/tcg/ (Paolo)
> - include in .inc.c relative to parent (Stefan)
>
On Thu, Dec 12, 2019 at 02:22:56PM +0530, Shivaprasad G Bhat wrote:
>
>
> On 12/11/2019 01:35 PM, Igor Mammedov wrote:
> > On Wed, 11 Dec 2019 09:44:11 +0530
> > Shivaprasad G Bhat wrote:
> >
> > > On 12/06/2019 07:22 AM, David Gibson wrote:
> > > > On Wed, Nov 27, 2019 at 09:50:54AM +0530,
On Thu, Dec 19, 2019 at 09:06:03AM -0500, Stefan Berger wrote:
> Extend the tpm_spapr frontend with VM suspend and resume support.
>
> Signed-off-by: Stefan Berger
> ---
> hw/tpm/tpm_spapr.c | 67 -
> hw/tpm/trace-events | 2 ++
> 2 files changed,
On Thu, Dec 19, 2019 at 09:06:05AM -0500, Stefan Berger wrote:
> Add an example to the TPM docs for how to add a TPM SPAPR
> device model to a QEMU VM emulating a pSeries machine.
>
> Signed-off-by: Stefan Berger
I don't see any advantage to splitting this out - it can be merged
into 3/6.
>
Hey Philippe,
On Thu, Jan 2, 2020 at 10:11 PM Philippe Mathieu-Daudé
wrote:
> Hi Niek,
>
> On 1/2/20 8:52 PM, Niek Linnenbank wrote:
> > Hi Philippe,
> >
> > I'm almost ready to send out v3 here.
> >
> > Now for documentation I'm not sure yet what to do:
> >
> > 1) Where should I place board
Hi Niek,
On 1/2/20 8:52 PM, Niek Linnenbank wrote:
Hi Philippe,
I'm almost ready to send out v3 here.
Now for documentation I'm not sure yet what to do:
1) Where should I place board documentation?
For example, the information that I wrote on the cover letter with
instructions on how
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
---
Hi,
The following series fixes a migration issue with the TPM PPI code due
to unaligned host RAM pointer.
Marc-André Lureau (2):
RFC: savevm: check RAM is page_size aligned
tpm-ppi: page-align PPI RAM
hw/tpm/tpm_ppi.c | 3 ++-
migration/savevm.c | 5 +
2 files changed, 7
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..ab6e02011f
When enlightened VMCS is enabled, certain VMX controls disappear, e.g.
posted interrupts for PINBASED_CTLS. With fine-grained VMX feature
enablement QEMU tries to do KVM_SET_MSRS with default (matching CPU
model) values and fails as KVM doesn't allow to set now-unsupported
controls.
The ideal
On 02.01.20 18:46, Igor Mammedov wrote:
> Previous patch drops silent ram_size fixup and makes
> QEMU error out with:
>
> "RAM size more than 3840m is not supported"
>
> when user specified -m X more than supported value.
>
> User shouldn't be bothered with starting QEMU with valid CLI,
> so for
On 02.01.20 16:49, Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
>> On Thu, 2 Jan 2020 15:17:14 +0100
>> Philippe Mathieu-Daudé wrote:
>>
>>> On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
>
Hi Philippe,
I'm almost ready to send out v3 here.
Now for documentation I'm not sure yet what to do:
1) Where should I place board documentation?
For example, the information that I wrote on the cover letter with
instructions on how to get the board up and running,
some description of
Hi
On Thu, Jan 2, 2020 at 3:03 PM Felipe Franciosi wrote:
> The reason I dislike yet another offloading protocol (ie. there is
> vhost, there is vfio, and then there would be qdev-over-socket) is
> that we keep reinventing the wheel. I very much prefer picking
> something solid (eg. VFIO) and
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 20 Dec 2019 01:40:35 +0530
> Kirti Wankhede wrote:
>
> > On 12/19/2019 10:57 PM, Alex Williamson wrote:
> >
> >
> >
> >
> > If device state it at pre-copy state (011b).
> > Transition, i.e., write to device state as
On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
Now that we don't use atomics for MIP we can change this back to a xlen
CSR.
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 2 +-
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience allow using -m 4G vs -m
On Thu, 2 Jan 2020 18:15:02 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 6:08 PM, Igor Mammedov wrote:
> > Previous patch drops silent ram_size fixup and makes
> > QEMU error out with:
> >
> > "RAM size more than 3840m is not supported"
> >
> > when user specified -m X more than supported
On Thu, 2 Jan 2020 18:14:32 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 5:50 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 16:49:00 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 15:17:14 +0100
> >>> Philippe
On Thu, 2 Jan 2020 16:52:50 +0100 (CET)
BALATON Zoltan wrote:
> On Thu, 2 Jan 2020, Igor Mammedov wrote:
> > On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
> > BALATON Zoltan wrote:
> >> On Tue, 31 Dec 2019, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
>
On 1/2/20 6:08 PM, Igor Mammedov wrote:
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of
On 1/2/20 5:50 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience to allow using -m 4G vs -m
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 15:17:14 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 13:06:33 +0100
> >>> Philippe
On Tue, Dec 17, 2019 at 04:33:16PM +, Stefan Hajnoczi wrote:
> On Mon, Dec 16, 2019 at 07:57:32PM +, Felipe Franciosi wrote:
> > > On 16 Dec 2019, at 20:47, Elena Ufimtseva
> > > wrote:
> > > On Fri, Dec 13, 2019 at 10:41:16AM +, Stefan Hajnoczi wrote:
> > >> Is there a
On Thu, 2 Jan 2020, Igor Mammedov wrote:
On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
BALATON Zoltan wrote:
On Tue, 31 Dec 2019, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by
Update: compiling qemu upstream & using the latest version didn't change
anything.
I don't know if this is an instance of user emulation limitations due to
missing syscalls.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe
On 1/2/20 4:35 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:41 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 12:31:58 +0100
> > Helge Deller wrote:
> >
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user
On 1/2/20 4:09 PM, Stefan Hajnoczi wrote:
On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote:
I'm not sure who is responsible of this...
Jeff maintains the web server and wiki.
I can look into things when Jeff is too busy, but lets see if he has
time in January.
Sure no
> On Jan 2, 2020, at 3:07 PM, Stefan Hajnoczi wrote:
>
> On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote:
>> Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道：
>>>
>>> On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote:
hi, stefan
I have faced the same problem you wrote in
On Mon, Dec 30, 2019 at 06:21:27PM +, Eltahawy, Mahmoud wrote:
> I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for
> qemu_set_fd_handler that the callback for reading from a file descriptor is
> delayed then expected while the file descriptor(socket) has a data to
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> 5. A jailer is needed to isolate the QEMU process and vhost-user
> device backends using seccomp, Linux namespaces, and maybe
> SELinux/AppArmor. We used to be able to rely on libvirt for QEMU
> security, but it's becoming a common task for any
On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote:
> I'm not sure who is responsible of this...
Jeff maintains the web server and wiki.
I can look into things when Jeff is too busy, but lets see if he has
time in January.
Stefan
signature.asc
Description: PGP signature
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 13:06:33 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 12:31 PM, Helge Deller wrote:
> >>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>
On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote:
> Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道：
> >
> > On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote:
> > > hi, stefan
> > >
> > > I have faced the same problem you wrote in
> > >
* Markus Armbruster (arm...@redhat.com) wrote:
> Stefan Hajnoczi writes:
> > 4. Go and Rust bindings would also be useful. There is
> > https://github.com/intel/govmm but I think it makes sense to keep it
> > in qemu.git and provide an interface similar to our Python modules.
>
> Mapping
On Mon, Dec 23, 2019 at 04:18:20PM +0300, Denis Plotnikov wrote:
> 1. virtqueue_size is a power of 2
> 2. virtqueue_size > 2, since seg_max is virtqueue_size - 2
>
> Signed-off-by: Denis Plotnikov
> ---
> hw/virtio/virtio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff
Hi,
Here's an interesting crash I've seen pop up since enabling CONFIG_JUMP_LABEL=y:
[4.716238] EIP: secure_tcp_seq+0x1e/0xa0^M
[4.716238] Code: c1 e8 46 90 fb ff eb a2 8d 74 26 00 55 89 e5 83
ec 18 89 75 f8 89 c6 0f b7 45 08 89 5d f4 0f b7 d9 89 7d fc 89 d7 89
45 ec 3e <8d> 74 26 00 8b
On Sat, Dec 21, 2019 at 10:02:23AM +0100, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
> > Hi,
> > QEMU presents a command-line interface and QMP monitor for
> > applications to interact with. Applications actually need API
> > bindings in their programming language. Bindings avoid
On Thu, 2 Jan 2020 14:02:01 +0100
Helge Deller wrote:
> On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> > On 1/2/20 12:31 PM, Helge Deller wrote:
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user provided non-sense RAM
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> > On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >> If user provided non-sense RAM size, board will complain and
> >> continue running with max RAM size supported.
> >> Also RAM is going to
On Tue, Dec 24, 2019 at 01:00:35PM +, Daniel P. Berrangé wrote:
> On Fri, Dec 20, 2019 at 04:13:59PM +, Stefan Hajnoczi wrote:
> > Hi,
> > QEMU presents a command-line interface and QMP monitor for
> > applications to interact with. Applications actually need API
> > bindings in their
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will
Le 02/01/2020 à 13:01, Jason A. Donenfeld a écrit :
> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
> looks at the rombase (or uses 0x4080 is there's no rombase), adds
> 0xa, and jumps to that address. At the
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
> > On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >>> continue
I think you should investigate
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in
I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="".
** Attachment added: "emerge.log"
https://bugs.launchpad.net/qemu/+bug/1857811/+attachment/5317106/+files/emerge.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Thu, Jan 2, 2020 at 12:41 PM Laurent Vivier wrote:
>
> Le 02/01/2020 à 12:10, Laurent Vivier a écrit :
> > Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit :
> >> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> >> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
In a native chroot, `sudo unshare --pid -- echo hello world` works
without a problem.
In a qemu-aarch64 chroot, `sudo unshare --keep-caps --pid -- echo hello
world` fails with the same error described in this issue.
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug
According to `man unshare`, --keep-caps seems to apply only to user
namespace.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 19.12.2019 um 15:26 hat Max Reitz geschrieben:
> > On 17.12.19 15:59, Kevin Wolf wrote:
> > > This tests creating an external snapshot with VM state (which results in
> > > an active overlay over an inactive backing file, which is also the root
> > >
On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size
On Thu, Jan 2, 2020 at 3:55 PM Marc-André Lureau
wrote:
>
> The following changes since commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191219' into
> staging (2019-12-20 16:37:07 +)
>
> are available in the Git repository at:
PID namespace prevents to execute some syscalls, even if you use --map-
root-user. This is managed at kernel level by the capabilities.
Could you try to do the exact same thing with the native architecture
binaries in the chroot to see if the problem really comes from qemu-
user?
Could you try
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it
Could you run qemu unimplemented error trace, by using "export
QEMU_LOG=unimp"?
You can also set the QEMU_STRACE="" to see which syscall fails.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
On Linux, calling `reboot(RB_AUTOBOOT);` will result in
arch/m68k/mac/misc.c's mac_reset function being called. That in turn
looks at the rombase (or uses 0x4080 is there's no rombase), adds
0xa, and jumps to that address. At the moment, there's nothing there, so
the kernel just crashes when
This will allow to pre-open the file before running the async finish
handler and avoid potential monitor fdset races.
(note: this is preliminary work for asynchronous screendump support)
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c| 45
Don't attempt to remove /dev/fdset files.
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/console.c b/ui/console.c
index 587edf4ed4..e6ac462aa0 100644
--- a/ui/console.c
+++ b/ui/console.c
1 - 100 of 127 matches
Mail list logo
