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
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 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
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
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
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
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
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
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
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
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 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 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 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 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 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
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
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
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
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
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
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
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
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
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:
(+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
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
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
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
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
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
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'.
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
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
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 `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
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
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
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
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
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
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
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
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
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
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 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
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
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
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: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
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 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 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 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
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 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
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 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
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
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’:
/
(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
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
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
101 - 167 of 167 matches
Mail list logo
