This corrects rather confusing error messages; can be squashed.
Fixes: 0afa2635ef75 ("spapr: Support NVIDIA V100 GPU with NVLink2", 2019-03-12)
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/spapr_pci_nvlink2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/spap
Nice catch!
Reviewed-by: Dmitry Fleytman mailto:dmitry.fleyt...@gmail.com>>
> On 21 Mar 2019, at 3:35, yuchenlin wrote:
>
> Ping?
>
> On 2019-03-13 14:56, yuchen...@synology.com wrote:
>> From: yuchenlin
>> Due to too early RCT0 interrput, win10x32 may hang on booting.
>> This problem can be
(1) I've gotten this one for a while:
/work/armbru/qemu/trace/ftrace.c: In function ‘ftrace_init’:
/work/armbru/qemu/trace/ftrace.c:56:37: warning: ‘%s’ directive output may
be truncated writing up to 8 bytes into a region of size between 1 and 4096
[-Wformat-truncation=]
sn
Yesterday's "dnf upgrade" on my F28 box upgraded gcc to
gcc-8.2.1-6.fc28.x86_64 from 8.3.1-2.fc28.x86_64. Since then (I think),
builds fail for me, details appended. Any ideas?
My temporary work-around is configure --disable-tcg.
/work/armbru/qemu/tcg/tcg-op.c: In function ‘tcg_gen_clz_i32’:
/
On Wed, Mar 20, 2019 at 04:05:58PM +0800, chenxi He wrote:
> On Wed, 20 Mar 2019 at 13:07, Peter Xu wrote:
> >
> > On Tue, Mar 19, 2019 at 11:49:22AM -0400, Catherine Ho wrote:
> > > Commit 18269069c310 ("migration: Introduce ignore-shared capability")
> > > addes a ignore-shared capability to byp
On 3/20/19 7:15 AM, Yoshinori Sato wrote:
> +/* [ri, rb] */
> +static inline void rx_gen_regindex(DisasContext *ctx, TCGv mem,
Please drop all of the inline markers.
Let the compiler choose which are profitable to inline.
> +/* load source operand */
> +static inline TCGv rx_load_source(DisasCon
Public bug reported:
Git commit hash where bug was reproduced:
62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2
A user of my application bVNC reported that when he connects to his VMs
running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8
appear in the VM respectively. I built the latest Qe
On Wed, Mar 20, 2019 at 08:50:40PM -0700, Richard Henderson wrote:
> On 3/20/19 5:39 PM, David Gibson wrote:
> > On Thu, Mar 14, 2019 at 08:26:28PM -0700, Richard Henderson wrote:
> >> We now have an interface for guest visible random numbers.
> >>
> >> Cc: qemu-...@nongnu.org
> >> Cc: David Gibson
I have requested additional info in the other forum. While I wait on
reply there, i will say, since you dont know it well, that Unraid is a
disto built on top of slackware. Are there any basic command line
commands that i could run to get the output you requested, or something
to keep things moving
On Tue, Mar 12, 2019 at 07:21:03PM +1100, Alexey Kardashevskiy wrote:
> NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
> space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
> implements special regions for such GPUs and emulates an NVLink bridge.
> NVL
On 3/20/19 5:39 PM, David Gibson wrote:
> On Thu, Mar 14, 2019 at 08:26:28PM -0700, Richard Henderson wrote:
>> We now have an interface for guest visible random numbers.
>>
>> Cc: qemu-...@nongnu.org
>> Cc: David Gibson
>> Signed-off-by: Richard Henderson
>
> Acked-by: David Gibson
>
> Do you
On Wed, Mar 20, 2019 at 09:46:42AM -0300, Maxiwell S. Garcia wrote:
> On Thu, Mar 14, 2019 at 06:26:02PM +0100, Greg Kurz wrote:
> > On Thu, 14 Mar 2019 13:29:49 -0300
> > "Maxiwell S. Garcia" wrote:
> >
> > > This adds a handler for ibm,get-vpd RTAS calls, allowing pseries guest
> > > to collect
On Thu, Mar 14, 2019 at 08:26:28PM -0700, Richard Henderson wrote:
> We now have an interface for guest visible random numbers.
>
> Cc: qemu-...@nongnu.org
> Cc: David Gibson
> Signed-off-by: Richard Henderson
Acked-by: David Gibson
Do you want me to take this through my tree?
> ---
> targe
On Tue, Mar 19, 2019 at 02:16:44PM +, Anthony PERARD wrote:
> On Mon, Mar 18, 2019 at 10:43:12PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 18, 2019 at 06:37:31PM +0100, Roger Pau Monne wrote:
> > > Or if it's not possible to honor the hinted address an error is returned
> > > ins
On 3/20/19 7:27 AM, Yoshinori Sato wrote:
> Hi.
> I found some problem in tested RX instructions.
> It is usable in RX instructions, but I think that there
> is a better fix because I am not familiar with Python.
The patch itself look ok, but needs some changes.
> I fixed three point.
> - Added c
Ping?
On 2019-03-13 14:56, yuchen...@synology.com wrote:
From: yuchenlin
Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will happen
On 3/20/19 7:05 AM, Yoshinori Sato wrote:
> OK. fixed another way.
> But RX big-endian mode only data access.
> So operand value always little-endian order.
Oh that is convenient.
Therefore the operand can always be put together by pieces. E.g.
-%b4_dsp_16 0:16 !function=dsp16
-%b4_bdsp
The irq is incorrectly calculated to be off by one. It has worked in the
past as the priority_base offset has also been set incorrectly. We are
about to fix the priority_base offset so first first the irq
calculation.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_plic.c | 4 ++--
1 file ch
According to the FU540 manual the PLIC source priority address starts at
an offset of 0x04 and not 0x00. The same manual also specifies that the
PLIC only has 53 source priorities. Fix these two incorrect header
files.
We also need to over extend the plic_gpios[] array as the PLIC sources
count fr
Update the virt offsets based on the newly updated SiFive U and SiFive E
offsets.
Signed-off-by: Alistair Francis
---
include/hw/riscv/virt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index f12deaebd6..568764b570 100644
According to the FE31 manual the PLIC source priority address starts at
an offset of 0x04 and not 0x00.
Signed-off-by: Alistair Francis
---
include/hw/riscv/sifive_e.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/riscv/sifive_e.h b/include/hw/riscv/sifive_e.h
in
Instead of using error_report() to print guest errors let's use
qemu_log_mask(LOG_GUEST_ERROR,...) to log the error.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_plic.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifiv
On 3/20/19 5:09 PM, Aleksandar Markovic wrote:
> This patch is really large.How about splitting it into a dozen of smaller
> logical groups? Also, a successful build (both gcc and clang kinds) is
> required after each patch.
Successful builds are often not feasible for new ports, since most ofte
This series updates the PLIC address to match the documentation.
This fixes: https://github.com/riscv/opensbi/issues/97
Alistair Francis (5):
riscv: plic: Fix incorrect irq calculation
riscv: sifive_u: Fix PLIC priority base offset and numbering
riscv: sifive_e: Fix PLIC priority base offse
Hi Paolo,
(+libvir-list)
I'd like to report a regression introduced by this patch set:
On 03/07/19 21:58, Paolo Bonzini wrote:
> The following changes since commit
> 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6:
>
> Merge remote-tracking branch
> 'remotes/cleber/tags/python-next-pull-request' in
Hi All,
Sorry for going straight to the developers but I have a very complex problem.
I have QNX application/OS that is licensed to the physical media it exists
on(media ID). When you boot on bare metal directly from the media all is good.
When I boot form the media in QEMU it acts like the m
arm and i386 has almost the same function acpi_add_rom_blob(), except
giving different FWCfgCallback function.
This patch moves acpi_add_rom_blob() to utils.c by passing
FWCfgCallback to it.
Signed-off-by: Wei Yang
---
v4:
* extract -> moves
* adjust comment in source to make checkpatch hap
On Wednesday, March 20, 2019, Yoshinori Sato
wrote:
> 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
> ---
Hello,, Yoshinori.
This patch is really
Le mer. 20 mars 2019 21:05, Philippe Mathieu-Daudé a
écrit :
> Le mer. 20 mars 2019 20:43, Laszlo Ersek a écrit :
>
>> On 03/20/19 19:59, Laszlo Ersek wrote:
>> > (+Daniel and MST)
>> >
>> > On 03/20/19 16:58, Peter Maydell wrote:
>>
>> >> A question: does this absolutely have to be 'xz' and not
The `make docker-travis@IMAGE` is broken because:
1) travis.py fails to parse the current .travis.yml
2) The travis script does not get the correct reference
to the source directory. It is a regression introduced on
commit 05790dafef1.
Tested with `make docker-travis@ubuntu`.
Wainer dos Santos Mo
Fixed the travis.py script that has failed to parse the current
QEMU_SRC/.travis.yml file. It no longer makes combinations from
env/matrix, instead it uses explicit includes. Also the compiler
can be omitted from matrix/include, so that Travis chooses the
first entry of the global compiler list.
R
The script generated from QEMU_SRC/.travis.yml uses BUILD_DIR and
SRC_DIR path relative to the current dir, unless these variables
are exported in environment.
Since commit 05790dafef1 BUILD_DIR is exported in the runner script,
although SRC_DIR is not, so that make docker-travis fails becase
the
On Tue, Mar 19, 2019 at 12:10 PM Peter Maydell wrote:
>
> On Tue, 19 Mar 2019 at 18:24, Alistair Francis
> wrote:
> >
> > Signed-off-by: Alistair Francis
> > ---
> > target/riscv/cpu.c | 10 --
> > target/riscv/cpu.h | 1 -
> > 2 files changed, 11 deletions(-)
>
> Won't this break lin
Folks,
If qemu tree is already fully built, and "make" is attempted, for 3.1, the
outcome is:
$ make
CHK version_gen.h
$
For 4.0-rc0, the outcome seems to be different:
$ make
make[1]: Entering directory '/home/build/malta-mips64r6/qemu-4.0/slirp'
make[1]: Nothing to be done for 'all'.
I don't know anything about unraid unfortunately; so I suggest you go
back to their forums and ask how to get the backtrace.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1821054
Title:
qemu segfau
Le mer. 20 mars 2019 20:43, Laszlo Ersek a écrit :
> On 03/20/19 19:59, Laszlo Ersek wrote:
> > (+Daniel and MST)
> >
> > On 03/20/19 16:58, Peter Maydell wrote:
>
> >> A question: does this absolutely have to be 'xz' and not bzip ?
> >
> > I think bzip2 should work fine too:
> >
> > 1146804 ed
FYI: I was happy to find the board and I'm hopeful to get it working. My
goal is to use old hardware to make a retro gaming machine for my girls
to play games I used to play growing up.
1)No its the qemu installed with unraid version 6.6.7, which i believe is qemu
3.0
2)im willing to get any note
On 03/20/19 19:59, Laszlo Ersek wrote:
> (+Daniel and MST)
>
> On 03/20/19 16:58, Peter Maydell wrote:
>> A question: does this absolutely have to be 'xz' and not bzip ?
>
> I think bzip2 should work fine too:
>
> 1146804 edk2-aarch64-code.fd.xz | 1177603 edk2-aarch64-code.fd.bz2
> 11
On 19/03/2019 17:21, Richard Henderson wrote:
> Changes since v2:
> * Several generic tcg patches to improve dup vs dupi vs dupm.
>
> In particular, if a global temp (like guest r10) is not in
> a host register, we should duplicate from memory instead of
> loading to an integer regi
(+Daniel and MST)
On 03/20/19 16:58, Peter Maydell wrote:
> On Wed, 20 Mar 2019 at 15:31, Laszlo Ersek wrote:
>>
>> Hi Peter,
>>
>> On 03/19/19 10:22, Peter Maydell wrote:
>>> On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé
>>> wrote:
Hi Peter,
Le dim. 17 mars 2019 23:02
Anthony PERARD writes:
> On Tue, Mar 19, 2019 at 07:34:45PM +0100, Markus Armbruster wrote:
>> = hw/xenpv/xen_machine_pv.c =
>> Stefano Stabellini (supporter:X86)
>> Anthony Perard (supporter:X86)
>> Paul Durrant (supporter:X86)
>> xen-de...@lists.xenproject.org (open list:
Bastian Koppelmann writes:
> On 3/18/19 8:30 AM, Markus Armbruster wrote:
>> Bastian Koppelmann writes:
>>
>>> On 3/12/19 6:36 PM, Markus Armbruster wrote:
>>> [snip]
= hw/tricore/tricore_testboard.c =
Bastian Koppelmann
(maintainer:TriCore)
>>>
>>> I created a patch
hmm that's a fun board.
It looks like qemu has segfaulted;
1) is this a qemu build you built yourself? If so, exactly which version,
built on which distro?
2) Could you get a backtrace of qemu crashing - this might be easiest if
your distro records core dumps somewhere.
--
You received
Patchew URL:
https://patchew.org/QEMU/20190320174150.12067-1-berra...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
tim
On 20/03/2019 17:18, Daniel P. Berrangé wrote:
> Changed in v4:
>
> - Drop support for systems without __NR_gettid
> - Keep using syscall0 macro
>
> Changed in v3:
> - put { on separate line to please checkpatch
>
> Changed in v2:
> - Rename to sys_gettid instead of using conditional compila
Public bug reported:
All the information I have is located in the Unraid forum on post
"https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor";
I am happy to provide any addition information requested. Please let me know.
Reporting bug here based on recommenda
Watch IDs are allocated from incrementing a int counter against
the QFileMonitor object. In very long life QEMU processes with
a huge amount of USB MTP activity creating & deleting directories
it is just about conceivable that the int counter can wrap
around. This would result in incorrect behaviou
The watch IDs are mistakenly only unique within the scope of the
directory being monitored. This is not useful for clients which are
monitoring multiple directories. They require watch IDs to be unique
globally within the QFileMonitor scope.
Reviewed-by: Marc-André Lureau
Tested-by: Bandan Das
R
The current file monitor unit tests are too clever for their own good
making it hard to understand the desired output.
Instead of trying to infer the expected events, explicitly list the
events we expect in the operation sequence.
Instead of dynamically building a matrix of tests, just have one g
On 3/20/19 9:18 AM, Daniel P. Berrangé wrote:
> Daniel P. Berrangé (2):
> linux-user: assume __NR_gettid always exists
> linux-user: rename gettid() to sys_gettid() to avoid clash with glibc
Reviewed-by: Richard Henderson
r~
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
are available in the Git repository at:
https://github.com/berrange/qemu tags/filemon-next-pull-request
for you to fetch changes up to 9c8cc692ccda6
On 3/1/19 7:20 AM, Thomas Huth wrote:
> iotest 235 currently only works with KVM - this is bad for systems where
> it is not available, e.g. CI pipelines. The test also works when using
> "tcg" as accelerator, so we can simply add that to the list of accelerators,
> too. But still, there might b
On Wed 20 Mar 2019 10:35:27 AM CET, Vladimir Sementsov-Ogievskiy wrote:
>> Maybe at least this kind of freezing isn't the right tool for block
>> jobs, after all.
>
> I think, the correct way, which will support these correct cases
> (which however don't look like real use cases) is removing base f
On 2/27/19 8:18 AM, Max Reitz wrote:
> On 27.02.19 14:14, Vladimir Sementsov-Ogievskiy wrote:
>> No reasons for not reporting found corruptions as corruptions in case
>> of some internal errors, especially in case of just failed to fix l2
>> entry (and in this case, missed corruptions may influe
On Fri, Mar 15, 2019 at 12:28 PM Andrew Cooper
wrote:
>
> On 15/03/2019 09:17, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jason Andryuk [mailto:jandr...@gmail.com]
> >> Sent: 14 March 2019 18:16
> >> To: Paul Durrant
> >> Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.o
On 03/19/19 17:35, Markus Armbruster wrote:
> We reject undersized backends with a rather enigmatic "failed to read
> the initial flash content" error. For instance:
>
> $ qemu-system-ppc64 -S -display none -M sam460ex -drive
> if=pflash,format=raw,file=eins.img
> qemu-system-ppc64: Init
On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
>> Oh, I see. Let's use a shorter chain for simplicity:
>>
>>A <- B <- C <- D <- E
>
> Written from right to left, i.e. E being the base and A the top layer?
> We usually write things the other write round, I hope this doesn't get
> too con
On Wed, 20 Mar 2019 15:24:42 +
Daniel P. Berrangé wrote:
> On Wed, Mar 20, 2019 at 04:20:19PM +0100, Igor Mammedov wrote:
> > > This could be solved if QEMU has some machine type based property
> > > that indicates whether "memdev" is required for a given machine,
> > > but crucially *does no
We were never reporting the G_IO_HUP event when an end of file was hit
on the websocket channel.
We also didn't report G_IO_ERR when we hit a fatal error processing the
websocket protocol.
The latter in particular meant that the chardev code would not notice
when an eof/error was encountered on t
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
are available in the Git repository at:
https://github.com/berrange/qemu tags/qio-next-pull-request
for you to fetch changes up to dd154c4d9f48a44ad
On 3/20/19 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
> Test that mirror job actually resume on resume command after being
> automatically paused on ENOSPC error.
>
> It's a follow-up test for 8d9648cbf3e
> "blockjob: fix user pause in block_job_error_action"
>
> Signed-off-by: Vladimir
Hi,
On 03/19/19 03:30, Li Qiang wrote:
> The first patch adds a util function to get the fw_cfg file entry.
> And second adds the reboot-timeout test case.
>
> Li Qiang (2):
> tests: fw_cfg: add a function to get the fw_cfg file
> tests: fw_cfg: add reboot_timeout test case
>
> tests/fw_cfg
Changed in v4:
- Drop support for systems without __NR_gettid
- Keep using syscall0 macro
Changed in v3:
- put { on separate line to please checkpatch
Changed in v2:
- Rename to sys_gettid instead of using conditional compilation
Daniel P. Berrangé (2):
linux-user: assume __NR_gettid alwa
The glibc-2.29.9000-6.fc31.x86_64 package finally includes the gettid()
function as part of unistd.h when __USE_GNU is defined. This clashes
with linux-user code which unconditionally defines this function name
itself.
/home/berrange/src/virt/qemu/linux-user/syscall.c:253:16: error: static
declar
The gettid syscall was introduced in Linux 2.4.11. This is old enough
that we can assume it always exists and thus not bother with the
conditional backcompat logic.
Signed-off-by: Daniel P. Berrangé
---
linux-user/syscall.c | 8
1 file changed, 8 deletions(-)
diff --git a/linux-user/sy
On 19/03/2019 14:39, Heyi Guo wrote:
> Hi Christoffer and Steve,
>
>
> On 2019/3/15 16:59, Christoffer Dall wrote:
>> Hi Steve,
>>
>> On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
>>> Personally I think what we need is:
>>>
>>> * Either a patch like the one from Heyi Guo (save/res
The mail thread at [1] clarifies that the Xen blkif protocol requires that
sector based quantities should be interpreted strictly as multiples of
512 bytes. This patch modifies the xen-block code accordingly.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01600.html
Signed-of
Issue seems to be fixed with Windows 10 19H1 Insider Preview Build 18361
!
Quoting from Microsoft's Changelog:
"We fixed an issue preventing certain VMs from being able to install or update
Windows Insider Preview builds ..."
Seems this was no qemu issue after all, please close.
--
You receive
On Wed, 20 Mar 2019 at 15:31, Laszlo Ersek wrote:
>
> Hi Peter,
>
> On 03/19/19 10:22, Peter Maydell wrote:
> > On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Hi Peter,
> >>
> >> Le dim. 17 mars 2019 23:02, Peter Maydell
> >> a écrit :
> >>>
> >>> On Sun, 17 Mar 2019 a
On Wed, 20 Mar 2019 13:46:59 +
Daniel P. Berrangé wrote:
> On Wed, Mar 20, 2019 at 10:32:53AM -0300, Eduardo Habkost wrote:
> > On Wed, Mar 20, 2019 at 11:51:51AM +, Daniel P. Berrangé wrote:
> > > On Wed, Mar 20, 2019 at 11:26:34AM +0100, Igor Mammedov wrote:
> > [...]
[...]
> > If
Hi Peter,
On 03/19/19 10:22, Peter Maydell wrote:
> On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé
> wrote:
>>
>> Hi Peter,
>>
>> Le dim. 17 mars 2019 23:02, Peter Maydell
>> a écrit :
>>>
>>> On Sun, 17 Mar 2019 at 20:29, Peter Maydell
>>> wrote:
Hi; this fails to build on OSX and O
On Wed, Mar 20, 2019 at 04:20:19PM +0100, Igor Mammedov wrote:
> > This could be solved if QEMU has some machine type based property
> > that indicates whether "memdev" is required for a given machine,
> > but crucially *does not* actually activate that property until
> > several releases later.
>
On Wed, Mar 20, 2019 at 01:30:26PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 19, 2019 at 02:20:01PM -0300, Eduardo Habkost wrote:
> > On Tue, Mar 19, 2019 at 04:16:14PM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 19, 2019 at 10:35:33PM +0800, Tao Xu wrote:
> > > > On 3/19/2019 8:16 PM,
On Wed, Mar 20, 2019 at 11:46:20AM -0300, Eduardo Habkost wrote:
> On Wed, Mar 20, 2019 at 01:46:59PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 20, 2019 at 10:32:53AM -0300, Eduardo Habkost wrote:
> > > On Wed, Mar 20, 2019 at 11:51:51AM +, Daniel P. Berrangé wrote:
> > > > On Wed, Mar 2
On Wed, 20 Mar 2019 11:51:51 +
Daniel P. Berrangé wrote:
> On Wed, Mar 20, 2019 at 11:26:34AM +0100, Igor Mammedov wrote:
> > On Tue, 19 Mar 2019 14:51:07 +
> > Daniel P. Berrangé wrote:
> >
> > > On Tue, Mar 19, 2019 at 02:08:01PM +0100, Igor Mammedov wrote:
> > > > On Thu, 7 Mar 2
It looks like this has slipped through the cracks. I'm queueing
this series for -rc1.
On Fri, Jan 25, 2019 at 08:06:04PM -0200, Eduardo Habkost wrote:
> This series works around KVM bugs that affect the arch_capabilities
> feature. One bug made the feature be enabled incorrect on AMD hosts,
> a
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
are available in the Git repository at:
https://github.com/otubo/qemu.git tags/pull-seccomp-20190320
for you to fetch changes up to
On 3/13/19 12:31 PM, Jason J. Herne wrote:
This is to support booting from vfio-ccw dasd devices. We basically implement
the real hardware ipl procedure. This allows for booting Linux guests on
vfio-ccw devices.
vfio-ccw's channel program prefetch algorithm complicates ipl because most ipl
chann
From: Daniel P. Berrangé
The Mesa library tries to set process affinity on some of its threads in
order to optimize its performance. Currently this results in QEMU being
immediately terminated when seccomp is enabled.
Mesa doesn't consider failure of the process affinity settings to be
fatal to
On Tue, Mar 19, 2019 at 10:45:47AM +, Daniel P. Berrangé wrote:
> ping
Sorry for missing it. I'm queueing this for -rc1, thanks!
>
> On Thu, Mar 07, 2019 at 12:18:36PM +, Daniel P. Berrangé wrote:
> > This corrects the note about spec-ctrl and adds info about the stibp
> > flag that was
On Wed, Mar 20, 2019 at 01:52:26PM +, Stefan Hajnoczi wrote:
> On Fri, Mar 15, 2019 at 03:51:15PM +0100, Markus Armbruster wrote:
> > * Our use of header guards is rather sloppy. Sloppiness there can
> > lead to confusing compilation errors. The rest of the series cleans
> > up existing h
On Wed, Mar 20, 2019 at 01:46:59PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 20, 2019 at 10:32:53AM -0300, Eduardo Habkost wrote:
> > On Wed, Mar 20, 2019 at 11:51:51AM +, Daniel P. Berrangé wrote:
> > > On Wed, Mar 20, 2019 at 11:26:34AM +0100, Igor Mammedov wrote:
> > [...]
> > > > S
Paolo Bonzini writes:
> On 30/10/2018 13:21, Alex Bennée wrote:
>>
>> Paolo Bonzini writes:
>>
>>> This is a race that can happen when migrating TCG guests under load.
>>> It was introduced by the change to run vCPUs outside the big QEMU
>>> lock.
>>
>> Did this ever get re-spun?
>
> No, the i
Patchew URL:
https://patchew.org/QEMU/20190320141610.46305-1-ys...@users.sourceforge.jp/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190320141610.46305-1-ys...@users.sourceforge.jp
Subject: [Qemu-devel] [PATCH RFC v4 00/12] Ad
...and properly enable it when synthesizing a drive.
The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
to enable discard on a specified image. The code in
xen_block_driver_create() correctly parses this and uses it to set
'discard' to 'unamp' for the file_layer, but fails to
Hi.
I found some problem in tested RX instructions.
It is usable in RX instructions, but I think that there
is a better fix because I am not familiar with Python.
I fixed three point.
- Added ctx to !function args.
- Fixed group operaiton. varinsns required width field.
- Fixed symbol in decode_lo
Signed-off-by: Yoshinori Sato
---
target/rx/helper.h| 35
target/rx/helper.c| 147 +
target/rx/op_helper.c | 557 ++
3 files changed, 739 insertions(+)
create mode 100644 target/rx/helper.h
create mode 100644 target/rx/he
Signed-off-by: Yoshinori Sato
---
target/rx/cpu-qom.h | 52
target/rx/cpu.h | 201 ++
target/rx/cpu.c | 225
3 files changed, 478 insertions(+)
create mode 100644 target/rx/cpu-
Signed-off-by: Yoshinori Sato
---
include/disas/bfd.h |5 +
target/rx/disas.c | 1512 +++
2 files changed, 1517 insertions(+)
create mode 100644 target/rx/disas.c
diff --git a/include/disas/bfd.h b/include/disas/bfd.h
index 41b61c85f9..b2c34
Signed-off-by: Yoshinori Sato
---
target/rx/gdbstub.c | 112
target/rx/monitor.c | 38
target/rx/Makefile.objs | 11 +
3 files changed, 161 insertions(+)
create mode 100644 target/rx/gdbstub.c
create mode 100644 tar
Signed-off-by: Yoshinori Sato
---
configure | 8
default-configs/rx-softmmu.mak | 7 +++
include/sysemu/arch_init.h | 1 +
arch_init.c| 2 ++
hw/Kconfig | 1 +
5 files changed, 19 insertions(+)
create mode 100644 defau
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
---
include/hw/timer/renesas_cmt.h | 33 +++
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
---
target/rx/translate.c | 2305
target/rx/insns.decode | 628
This implementation supported only ICUa.
Hardware manual.
https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01uh0033ej0140_rx62n.pdf
Signed-off-by: Yoshinori Sato
---
include/hw/intc/rx_icu.h | 49 +++
hw/intc/rx_icu.c | 373 +++
Signed-off-by: Yoshinori Sato
---
MAINTAINERS | 19 +++
1 file changed, 19 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 85d7d764e5..046dbd8eb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,6 +272,13 @@ F: include/hw/riscv/
F: linux-user/host/riscv32/
F: linux
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
---
include/hw/char/renesas_sci.h | 45 ++
hw/char/renesas_sci.c | 335 +
rx62n - RX62N cpu.
rxqemu - QEMU virtual target.
Signed-off-by: Yoshinori Sato
---
include/hw/rx/rx.h| 7 ++
include/hw/rx/rx62n.h | 54
hw/rx/rx62n.c | 226 ++
hw/rx/rxqemu.c| 100 ++
hw/rx/K
Some RX peripheral using 8bit and 16bit registers.
Added 8bit and 16bit APIs.
Signed-off-by: Yoshinori Sato
---
include/hw/registerfields.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/hw/registerfields.h b/include/hw/registerfields.h
index 2659a58737..f6bf911990 10064
Hello.
This patch series is added Renesas RX target emulation.
Update review comments and fix some issue.
My git repository is bellow.
git://git.pf.osdn.net/gitroot/y/ys/ysato/qemu.git
Testing binaries bellow.
u-boot
Download - https://osdn.net/users/ysato/pf/qemu/dl/u-boot.bin.gz
starting
$ gz
On Tue, Mar 19, 2019 at 09:51:17AM +, Lilijun (Jerry, Cloud Networking)
wrote:
> After more detail test, I found two results:
> 1) This route entry's lost can be reproduced on both virtio-net and
> pass-through physical devices.
> 2) The link down event is handled by a service named NetworkM
1 - 100 of 167 matches
Mail list logo
