On 27/10/2018 01:33, Emilio G. Cota wrote:
> On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote:
>> On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
>
>> An idea: the total number of requests is going to be very small, and a
>> PtrRing is not the nicest data structure for multiple pro
This is useful to write qtest abount fw_cfg file entry.
Signed-off-by: Li Qiang
---
tests/libqos/fw_cfg.c | 30 ++
tests/libqos/fw_cfg.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/tests/libqos/fw_cfg.c b/tests/libqos/fw_cfg.c
index d0889d1e22..2dd7a498ab
This patchset is the test case for the following patch:
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg05254.html
Li Qiang (2):
tests: fw_cfg: add a function to get the fw_cfg file entry
tests: fw_cfg: add reboot_timeout test case
tests/fw_cfg-test.c | 13 -
tests/li
Signed-off-by: Li Qiang
---
tests/fw_cfg-test.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/fw_cfg-test.c b/tests/fw_cfg-test.c
index 1c5103fe1c..37765f15f8 100644
--- a/tests/fw_cfg-test.c
+++ b/tests/fw_cfg-test.c
@@ -99,6 +99,15 @@ static void test_f
Hi!
I just happened to read Gerd Hoffmann's post on the bochs-display [1] driver
and was wondering what the future plans for VGA support are.
Phoronix makes it sound like [2] that VGA support for guests is supposed to
be removed which I find hard to believe. Since once VGA support is gone,
QEMU w
On 28 October 2018 at 05:43, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>> Something I meant to bring up but forgot is about the classification
>> of devices, especially with a view towards security. It is not directly
>> about deprecation, but it is somewhat related as it is related
> Subject: [PATCH v7 10/20] target/mips: Add bit encoding for MXU operand
> getting pattern 'optn3'
>
> From: Craig Janeczek
>
> Add bit encoding for MXU operand getting pattern 'optn3'.
>
> Signed-off-by: Craig Janeczek
> Signed-off-by: Aleksandar Markovic
---
Reviewed-by: Aleksandar Marko
> Subject: [PATCH v7 09/20] target/mips: Add bit encoding for MXU operand
> getting pattern 'optn2'
>
> From: Craig Janeczek
>
> Add bit encoding for MXU operand getting pattern 'optn2'.
>
> Signed-off-by: Craig Janeczek
> Signed-off-by: Aleksandar Markovic
> ---
Reviewed-by: Aleksandar Mar
> Subject: [PATCH v7 07/20] target/mips: Add bit encoding for MXU accumulate
> add/sub 2-bit pattern 'aptn2'
>
> From: Craig Janeczek
>
> Add bit encoding for MXU accumulate add/subtract 2-bit pattern
> 'aptn2'.
>
> Signed-off-by: Craig Janeczek
> Signed-off-by: Aleksandar Markovic
> ---
Re
> Is the best way to implement this to include processing of MUL, CLZ,
> CLO, SDBBP instructions into decode_opc_mxu as their encodings aren't
> overlaid by MXU instructions considering MIPS SPECIAL2 instruction
> pool and MXU Instruction Set?
The problem is that we don't have the documentation fo
> Subject: [PATCH v7 02/20] target/mips: Define a bit for MXU in insn_flags
>
> From: Craig Janeczek
>
> Define a bit for MXU in insn_flags. This is the first non-MIPS
> (third party) ASE supported in QEMU for MIPS, so it is placed in
> the section "bits 56-63: vendor-specific ASEs".
>
> Signed
> Subject: [PATCH v7 12/20] target/mips: Add emulation of MXU instructions
> S32I2M and S32M2I
>
> From: Craig Janeczek
>
> Add support for emulating the S32I2M and S32M2I MXU instructions.
> This commit also contains utility functions for reading/writing
> to MXU registers. This is required fo
> Subject: [PATCH v7 11/20] target/mips: Add emulation of non-MXU MULL within
> MXU decoding engine
>
> From: Craig Janeczek
>
> Add emulation of non-MXU MULL within MXU decoding engine.
>
> Signed-off-by: Craig Janeczek
> Signed-off-by: Aleksandar Markovic
> ---
Reviewed-by: Aleksandar Mar
> Subject: Re: [PATCH v7 04/20] target/mips: Add and integrate MXU decoding
> engine > placeholder
>
> > Is the best way to implement this to include processing of MUL, CLZ,
> > CLO, SDBBP instructions into decode_opc_mxu as their encodings aren't
> > overlaid by MXU instructions considering MIPS
> From: Richard Henderson
> Sent: Tuesday, October 16, 2018 8:37 PM
> Subject: Re: [PATCH] target/mips: Support Toshiba specific three-operand MADD
> and MADDU
>
> On 10/16/18 11:19 AM, Fredrik Noring wrote:
> > /* global register indices */
> > static TCGv cpu_gpr[32], cpu_PC;
> > static TCGv c
On Sun, 28 Oct 2018, Aleksandar Markovic wrote:
> I truly need your help here. As you can conclude from the discussion,
> R5900 folks (anybody correct me if I am wrong) have some problems using
> any ABI other than O32.
The maximum the R5900 can support is the n32 ABI, owing to 32-bit virtual
Hi,
anyone wants to talk about emulating oldies with QEMU?
François.
Message transféré
Sujet : [retrocomputing devroom] FOSDEM 2019 - Retrocomputing DevRoom CfP
Date : Sun, 28 Oct 2018 23:12:58 +0100
De : Pau Garcia Quiles
Pour : FOSDEM visitors
Copie à : retrocomputing-devr
** Attachment added: "Gentoo.sh -- systemrescuecd-x86-5.3.1 -- dmesg.log"
https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206600/+files/Gentoo.sh%20--%20systemrescuecd-x86-5.3.1%20--%20dmesg.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which
** Attachment added: "Shell script used to invoke qemu with vga-passthrough and
qxl graphics emulation"
https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206603/+files/Gentoo_qxl.sh
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
** Attachment added: "Shell script used to invoke qemu with only
vga-passthrough"
https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206602/+files/Gentoo.sh
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
** Attachment added: "Gentoo_qxl.sh -- systemrescuecd-x86-5.3.1 -- dmesg.log"
https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206601/+files/Gentoo_qxl.sh%20--%20systemrescuecd-x86-5.3.1%20--%20dmesg.log
--
You received this bug notification because you are a member of qemu-
devel-ml
Public bug reported:
The EFI framebuffer fails to load when booting a Gentoo guest using ovmf
+ vga_passthrough. I retested using they system rescue CD and saw the
same issue, but also noticed that when a second framebuffer loads,
nouveaufb in my case, the terminal appears. I have also verified
The OVMF BIOS used can be downloaded from
https://dev.gentoo.org/~tamiko/distfiles/edk2-ovmf-
2017_p20180211-bin.tar.xz
System information via 'emerge --info' is also provided below.
Portage 2.3.51 (python 3.6.6-final-0, default/linux/amd64/17.1/desktop,
gcc-8.2.0, glibc-2.27-r6, 4.19.0-gentoo x
On 10/28/2018 03:50 PM, Paolo Bonzini wrote:
On 27/10/2018 01:33, Emilio G. Cota wrote:
On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote:
On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
An idea: the total number of requests is going to be very small, and a
PtrRing is not t
Currently, when hotplug/unhotplug nvme device, it will cause an
assert in object.c. Following is the backtrack:
ERROR:qom/object.c:981:object_unref: assertion failed: (obj->ref > 0)
Thread 2 "qemu-system-x86" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffcbd32700 (LWP 18844)]
0x000
The first corrent the refcount and second fix a memory leak.
Li Qiang (2):
nvme: don't unref ctrl_mem when device unrealized
nvme: free cmbuf in nvme_exit
hw/block/nvme.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.11.0
This avoid a memory leak in unhotplug nvme device.
Signed-off-by: Li Qiang
---
hw/block/nvme.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 359a06d0ad..09d7c90259 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1332,6 +1332,9 @@ static voi
On 10/26/18 4:22 PM, Eduardo Habkost wrote:
On Fri, Oct 26, 2018 at 01:53:10PM +0800, Tao Xu wrote:
On 10/25/18 9:28 PM, Eduardo Habkost wrote:
Sorry for taking so long to reply. This can be safely done only
if every host that is able to run Skylake-Server today is
guaranteed to support PKU
Hi
On Mon, Oct 22, 2018 at 5:24 PM Yury Kotov wrote:
>
> Hi,
>
> I examined vhost-user devices and found some chardev using strangeness.
>
> Is it ok, that vhost-user's set_status do sync chardev io ops from KVM thread?
> It seems that chardev doesn't support working with different threads.
>
> F
Hi
On Tue, Oct 9, 2018 at 8:41 PM Markus Armbruster wrote:
>
> Markus Armbruster writes:
>
> > Thomas Huth writes:
> >
> >> On 2018-08-31 15:24, Marc-André Lureau wrote:
> >>> Hi
> >>> On Fri, Aug 31, 2018 at 3:18 PM Thomas Huth wrote:
>
> On 2018-08-31 14:04, Markus Armbruster wrote
30 matches
Mail list logo
