ue, rather than fail, I/O requests when disconnected
Signed-off-by: Nick Thomas
---
block/nbd.c | 54 --
1 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 1caae89..e55a9a7 100644
--- a/block/n
the curent
situation, and I'd rather like some feedback on the best way to do
the futher bits - assuming these patches get eventually accepted!
Nick Thomas (3):
nbd: Only try to send flush/discard commands if connected to the NBD
server
nbd: Explicitly disconnect and fail inflight I/O re
This is unlikely to come up now, but is a necessary prerequisite for
reconnection
behaviour.
Signed-off-by: Nick Thomas
---
block/nbd.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 2bce47b..9536408 100644
--- a/block
, as it can
lead to many
failed attempts to connect to the NBD server in short order, but at least
allows us to get
over temporary failures in this state.
Signed-off-by: Nick Thomas
---
block/nbd.c | 72 --
1 files changed, 49 insertions(
From: Nick Thomas
To do this, we start a qemu-nbd process at _make_test_img and kill
it in _cleanup_test_img. $TEST_IMG is changed to point at the TCP
server.
Signed-off-by: Nick Thomas
---
tests/qemu-iotests/common|7 +--
tests/qemu-iotests/common.config |8
From: Nick Thomas
To do this, we start a qemu-nbd process at _make_test_img and kill
it in _cleanup_test_img. $TEST_IMG is changed to point at the TCP
server. We also remove the checks for existence of binaries from
common.config - they're duplicated in common, and we can make the
qemu-nbd
In QEMU master, attempting to read a cached block from a HTTP (or otherwise)
mounted ISO causes an assert to be triggered, killing the entire QEMU process.
It looks like this:
hw/ide/pci.c:314: bmdma_cmd_writeb: Assertion `bm->bus->dma->aiocb ==
((void *)0)' failed.
The following two patches add
From: Nick Thomas
The previous behaviour was to finish AIOCBs inside curl_aio_readv()
if the data was cached. This caused the following failed assertion
at hw/ide/pci.c:314: bmdma_cmd_writeb
"Assertion `bm->bus->dma->aiocb == ((void *)0)' failed."
By scheduling a Q
From: Nick Thomas
Signed-off-by: Nick Thomas
---
block/curl.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index f3f61cc..21fed93 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -76,6 +76,7 @@ typedef struct
From: Nick Thomas
Signed-off-by: Nick Thomas
---
block/nbd.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 1d6b225..7a52f62 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -239,6 +239,10 @@ static int nbd_write(BlockDriverState *bs
From: Nick Thomas
This preserves the previous behaviour where the NBD server is
unavailable or goes away during guest execution, but switches the
NBD backend to present the AIO interface instead of the sync IO
interface.
We also split read & write requests into 1 MiB blocks (minus header).
cking connect() might not be an
issue while the KVM process is starting up, but could cause problems if we
try to reconnect while emulation is ongoing.
Thoughts?
/Nick
From: Nick Thomas
Signed-off-by: Nick Thomas
---
migration-tcp.c | 85 ---
1 files changed, 12 insertions(+), 73 deletions(-)
diff --git a/migration-tcp.c b/migration-tcp.c
index d3d80c9..8ae778e 100644
--- a/migration-tcp.c
+++ b
is appreciated. Thank you. :)
--
- Nick
outzider at fsckedhost.com
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Public bug reported:
Hi,
we are experiencing a quite high memory usage of a single qemu (used with KVM)
process when using RBD with client caching as a disk backend. We are testing
with 3GB memory qemu virtual machines and 128MB RBD client cache. When running
'fio' in the virtual machine you ca
Hello,
Cruising by the wki, thought that ARAnyM was a cool project.
Found it here: https://wiki.qemu.org/Links#Other_emulators
However, the link was out of date and now points to some
domain squatted site.
The updated link is: https://aranym.github.io/
Cheers!
-- Nick
Public bug reported:
The issue is happening on all versions I tried after the following
commit.
git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
af1b80ae56c9495999e8ccf7b70ef894378de642
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b7bc2a..7a5a8b3521 100644
--- a/hw/i386/a
** Description changed:
The issue is happening on all versions I tried after the following
- commit.
+ commit. I can also remove this individual from master and it starts to
+ work.
git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
af1b80ae56c9495999e8ccf7b70ef894378de642
diff --git a/h
** Description changed:
The issue is happening on all versions I tried after the following
commit. I can also remove this individual change from master and it
starts to work.
+
+ OVMF_CODE.fd is what comes with Ubuntu 20.04 through package manager.
+
git diff af1b80ae56c9495999e8ccf7b
I haven't tried a new install. Also, Michael asked to check
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
The code in question is changed there and it works fine for that existing image.
--
You received this bug notification because you are a member of qemu-
devel-ml, whi
Public bug reported:
i am trying to run Windows 10 x64 on Windows 10 x64 host with intel haxm
as kernel accelerator, but the system never boots, as far i read the
documentation everything should be fine...
the logs are qemu:
`
D:\vm>qemu-system-x86_64 -d
guest_errors,out_asm,in_asm,op,op_opt,o
Hi,
On 25/02/14 10:09, Stefan Hajnoczi wrote:
> The nbd-fault-injector.py script is a special kind of NBD server. It
> throws away all writes and produces zeroes for reads. Given a list of
> fault injection rules, it can simulate NBD protocol errors and is useful
> for testing NBD client error h
gin, or even if it's possible at all. Are these CPUs just too old, or
is a fixup missing in qemu (or kvm)?
/Nick
On 28/02/14 12:57, Paolo Bonzini wrote:
> Il 28/02/2014 13:16, Nick Thomas ha scritto:
>> I'd love to get this working, but I'm a little ignorant on where to
>> begin, or even if it's possible at all. Are these CPUs just too old, or
>> is a fixup missing in qem
backwards time was visible in the guest.
>
> I've managed to get my hands on a broken migration stream from Nick.
> There I looked at the curr_clocksource structure and saw that the last
> seen time on the kvmclock clock source was greater than the value that
> the kvmclo
o
> naturally aligned addresses in write-back cacheable memory.)
>
> Oh, that's interesting. Way back when I guess we knew writes were in
> order and it wasn't explicit that reads were, hence smp_rmb() using a
> locked atomic.
>
> Here is a post by Nick Piggin from 200
alid keyboard command.
Any help in tracking down the error would be greatly appreciated, and I'm happy
to do any debugging/testing necessary!
Thanks!
-Nick
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is
command 0xce
It looks like perhaps there are more instances where the IDE code
chooses to write to the wrong memory location. I can provide detailed
debug output if needed...
-Nick
>>> On 2009/12/13 at 15:41, Juan Quintela wrote:
> Igor Kovalenko wrote:
>> On Sun, Dec 13, 200
v version of it) under the BSD and GPL licenses.
What would it take to get Qemu to use the OBP code instead of OpenBIOS? Looks
like the OBP output isn't really an executable, and it seems like
sparc64-softmmu will only load Sparc ELF binaries for the BIOS.
Thanks - Nick
Thi
>>> On 2009/10/21 at 13:06, Blue Swirl wrote:
> On Wed, Oct 21, 2009 at 7:41 PM, Nick Couchman
> wrote:
>> I have a couple of questions regarding sparc64 softmmu support in Qemu:
>> - Is this part of Qemu being actively developed? Judging by the commits to
>
not supported?
Thanks - Nick
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is not intended for you, or you are
not responsible for the delivery of this message to the intended recipient,
please note that this me
There is no guarantee that the PCNetState is allocated such that
csr[8] is allocated on an 8-byte boundary. Since not all hosts are
capable of unaligned fetches the 16-bit elements need to be fetched
individually to avoid a potential fault. Closes issue #2143
Signed-off-by: Nick Briggs
---
hw
sts.infradead.org/mailman/listinfo/linux-riscv
You may use the hostfw argument on qemu, e.g...
-netdev user,id=unet,hostfwd=tcp::-:22 \
-net user \
and you 'll get guest's port 22 to be forwarded to hosts port , so
you can do
ssh root@localhost:
from the host.
Regards,
Nick
your VM?
Thanks,
Nick
In section 7.4.3 of the 82574 datasheet it states that
"In systems that do not support MSI-X, reading the ICR
register clears it's bits..."
Some OSes rely on this.
Signed-off-by: Nick Hudson
---
hw/net/e1000e_core.c | 5 +
hw/net/trace-events | 1 +
2 files change
In section 7.4.3 of the 82574 datasheet it states that
"In systems that do not support MSI-X, reading the ICR
register clears it's bits..."
Some OSes rely on this.
Signed-off-by: Nick Hudson
---
hw/net/e1000e_core.c | 5 +
hw/net/trace-events | 1 +
2 files change
hello there! i've been using qemu since about 2005, but somehow
never needed to make an account on the wiki. i now do. can i
get an account created for 'dankamongmen' or, if you prefer real
names, 'nickblack'? thanks!
--
nick black -=- https://www.nick-black.com
to make
On 2023-09-28, Richard Henderson wrote:
> On 9/24/23 01:03, Nick Bowler wrote:
>> All of the VIS subtraction instructions are documented to subtract the
>> second input operand from the first. This is also consistent with how
>> the instructions actually work on a real Ult
On 2023-09-28, Richard Henderson wrote:
> On 9/24/23 01:03, Nick Bowler wrote:
>> case 0x04b: /* VIS I fpmerge */
>> CHECK_FPU_FEATURE(dc, VIS1);
>> -gen_ne_fop_DDD(dc, rd, rs1, rs2,
doesn't
fix a bug, it should go in a separate patch.
So I will include a patch to do that in series v2 and keep this one
as-is with your Reviewed-by.
Thanks,
Nick
3, 4 and 5.
Emulation results are tested by manually comparing the output of a small
Linux test program on an UltraSparc II against the output of running the
same binary under qemu-sparc32plus on a ppc64le host system.
[1] https://gitlab.com/qemu-project/qemu/-/issues/1901
Nick Bowler (8
. Even if the inputs happen to be correct, the
emulator is rounding the output, which the real processor does not do.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 2 +-
target/sparc/vis_helper.c | 17 +++--
3 files changed, 9 insertions
except in trivial cases.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 19 ++-
target/sparc/vis_helper.c | 14 +-
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/target/sparc/helper.h b/target/sparc/helper.h
rounding the output, which the real processor does
not do. And the real processor shifts both outputs left by 8, which
the emulator does not do.
So the results are wrong except in trivial cases.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 2 +-
target
from the second, so the results are wrong
in all nontrivial cases.
Signed-off-by: Nick Bowler
---
target/sparc/vis_helper.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/target/sparc/vis_helper.c b/target/sparc/vis_helper.c
index 3903beaf5d..fa97e09ffa
instances.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 6 +-
target/sparc/vis_helper.c | 26 +-
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/target/sparc/helper.h b/target/sparc/helper.h
index
except in trivial cases.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 2 +-
target/sparc/vis_helper.c | 11 ++-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/target/sparc/helper.h b/target/sparc/helper.h
index 76e06b8ea5
therefore the output of the emulated instruction is
just garbage.
Signed-off-by: Nick Bowler
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1901
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 6 +-
target/sparc/vis_helper.c | 9 +
3 files changed, 11 insertions
the second.
This will not normally contain the correct data so the emulated
instruction usually just produces garbage.
Signed-off-by: Nick Bowler
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 5 -
target/sparc/vis_helper.c | 5 ++---
3 files changed, 7 insertions(+), 5
Solaris has #defines for htonll and ntohll which cause syntax errors
when compiling code that attempts to (re)define these functions..
Signed-off-by: Nick Briggs
---
migration/rdma.c | 4
1 file changed, 4 insertions(+)
diff --git a/migration/rdma.c b/migration/rdma.c
index 94c0f871f0
Solaris has net/if_arp.h and netinet/if_ether.h rather than net/ethernet.h,
but does not define ETHER_ADDR_LEN, instead providing ETHERADDRL.
Signed-off-by: Nick Briggs
---
qga/commands-posix.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qga/commands-posix.c b/qga
Thank you.
Yes, with those two patches applied I have compiled qemu on Solaris 11.4
running on a SPARC-T4-1 (sun4v) system to emulate a single target: an HP
PA-RISC.
> On Jan 14, 2024, at 8:35 PM, Peter Xu wrote:
>
> On Thu, Jan 11, 2024 at 01:20:17PM -0500, Nick Briggs wrote:
>&
i'm writing to discuss an issue in qemu's vpc creation.
when creating a dynamic-type vpc image with qemu-img like so:
$ qemu-img create -f vpc vhd.vhd 100M
Formatting 'vhd.vhd', fmt=vpc size=104857600
and then inspecting the file (with a tool i wrote; it's also easy to see in
a hex dump):
$ vhd
The aarch64 crypto instructions for AES and SHA are missing the
check for if the FPU is enabled.
Signed-off-by: Nick Reilly
---
target/arm/translate-a64.c | 12
1 file changed, 12 insertions(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index e61bbd6
have occupied.
Clarify the load_uimage API to state the passing of a load address when an
image doesn't specify one, or when loading a ramdisk is expected.
Adjust callers of load_uimage, etc.
Signed-off-by: Nick Hudson
---
hw/arm/boot.c | 8 +---
hw/core/loader.c
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry point is
adjusted appropriately
Signed-off-by: Nick Hudson
---
hw/arm/boot.c | 8
ping
On 07/11/2018 13:19, Nick Hudson wrote:
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry point is
adjusted appropriately
Signed-off-by
On 16/11/2018 14:34, Peter Maydell wrote:
On 7 November 2018 at 13:19, Nick Hudson wrote:
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry
have occupied.
Update the load_uimage API to allow passing of load address when an image
doesn't specify one.
Signed-off-by: Nick Hudson
---
hw/arm/boot.c | 8 +---
hw/core/loader.c | 15 ---
hw/core/uboot_image.h | 1 +
include/hw/loader.h | 3 ++-
4 files ch
On 30/11/2018 17:18, Peter Maydell wrote:
On Thu, 29 Nov 2018 at 20:22, Nick Hudson wrote:
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry
ping
On 11/12/2018 12:27, Nick Hudson wrote:
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry point is
adjusted appropriately.
The bootloader
ready implemented.
In addition, there's been talks with a different project that I might apply for.
I'll keep in touch if that changes, of course.
Cheers,
Nick Renieris.
Στις Πέμ, 17 Ιαν 2019 στις 11:29 π.μ., ο/η Stefan Hajnoczi
έγραψε:
>
> On Wed, Dec 26, 2018 at 1:29 AM Nick Renier
com/watch?v=IYHTwnde0g8)
,yet there doesn't seem to be a front-end (except for VEX prefix
parsing) nor a backend for AVX, a pretty common x86 extension.
I'd appreciate any info on this,
Regards,
Nick Renieris.
Hi Richard,
I did know about https://github.com/andikleen/qemu-avx but didn't
mention it as it seems abandoned and quite old (also it doesn't use
`TCGv_vec`).
Do you think this could work as a GSoC project? I'm potentially
interested in working on it this summer.
Thanks,
Nick R
ho thought it'd be a good
idea to put all this stuff in _one_ file?).
Another question, are there existing discussions about this
refactoring effort or specifically AVX? I asked a similar question on
IRC a few days ago and got no answers.
Στις Τετ, 26 Δεκ 2018 στις 4:12 π.μ., ο/η Richard Hend
Maydell
έγραψε:
>
> On Fri, 28 Dec 2018 at 13:45, Nick Renieris wrote:
> > Also, I hope you meant four months for me, not for you - I'm
> > completely new to the QEMU codebase. I expect it will take me weeks
> > just to understand x86's 'translate.c' (who tho
Στις Παρ, 28 Δεκ 2018 στις 4:39 μ.μ., ο/η Peter Maydell
έγραψε:
> If your editor can't show multiple views onto one file with
> the same simplicity and UI as it has for multiple different
> files then I would suggest getting a better editor :-)
Apparently I just didn't know how to use my editor :
Στις Σάβ, 29 Δεκ 2018 στις 10:24 μ.μ., ο/η Richard Henderson
έγραψε:
> I did have a beginner in mind when guessing 4 months. Don't take that as a
> fully speced out answer, but it may well be that full avx2 support cannot be
> done within the 3 months of gsoc. I would certainly expect avx512 to
On 03/01/2019 16:20, Peter Maydell wrote:
> On Tue, 11 Dec 2018 at 12:27, Nick Hudson wrote:
>>
>>
>> noload kernels are loaded with the u-boot image header and as a result
>> the header size needs adding to the entry point. Fake up a hdr so the
>> kernel ima
On 03/01/2019 17:27, Peter Maydell wrote:
On Thu, 3 Jan 2019 at 16:50, Nick Hudson wrote:
On 03/01/2019 16:20, Peter Maydell wrote:
On Tue, 11 Dec 2018 at 12:27, Nick Hudson wrote:
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -30,8 +30,9 @@
* Documentation/arm/Booting and
Στις Παρ, 4 Ιαν 2019 στις 11:51 μ.μ., ο/η Richard Henderson
έγραψε:
> As an integer it is always passed by value. As a structure some host abis
> pass
> it by reference, and the TCG compiler doesn't know about that.
Ah so they modify it? If so it could surely be worked around with
explicit stac
Ohh got it, thanks.
Στις Σάβ, 5 Ιαν 2019 στις 12:38 π.μ., ο/η Richard Henderson
έγραψε:
>
> On 1/5/19 8:33 AM, Nick Renieris wrote:
> > I know host ABI's can differ like that, but I don't understand why
> > that should matter. Everything (TCG compiler included) is co
Στις Σάβ, 5 Ιαν 2019 στις 12:14 π.μ., ο/η Richard Henderson
έγραψε:
> No, it's just calling conventions. And it could be worked around, but I think
> what we have is convenient enough.
>
> Especially since the sizes are encoded as (n+1)*8, which also shows the
> compiler that the size is positive
Right, that makes sense, thanks for the explanations. As someone with
very little x86 experience (zero experience from this perspective)
it's kind of daunting that I'd have to refactor all this stuff. All
these helpers via macros to get around C's 'minimalism' also seem like
something I'd have to g
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address and the entry point is
adjusted appropriately.
The default location for the uboot file is 32MiB above bottom o
problems already. I'm
avoiding i) fixing these in the same diff for clarity and ii) in the
case of IH_TYPE_KERNEL_NOLOAD, following existing formatting.
I'll send v5 with the loadaddr api documentation formatting fix.
Nick
Thanks for the comments.
On 07/01/2019 00:33, BALATON Zoltan wrote:
On Sun, 6 Jan 2019, Nick Hudson wrote:
noload kernels are loaded with the u-boot image header and as a result
the header size needs adding to the entry point. Fake up a hdr so the
kernel image is loaded at the right address
of DRAM.
This matches the recommendation in Documentation/arm/Booting.
Clarify the load_uimage API to state the passing of a load address when an
image doesn't specify one, or when loading a ramdisk is expected.
Adjust callers of load_uimage, etc.
Signed-off-by: Nick Hudson
---
hw/arm/b
error_setg_errno takes a positive error number, so we should not invert
errno's sign.
Signed-off-by: Nick Erdmann
---
hw/virtio/vhost-vsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
index 66da96583b..9f909
roups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20210211194258.4137998-1-nathan%40kernel.org.
--
Thanks,
~Nick Desaulniers
to using the incorrect index to
udev->altsetting.
Fix this problem by getting the interface number from the active
libusb_config_descriptor, and then using that as the index to
udev->altsetting.
Signed-off-by: Nick Rosbrook
---
hw/usb/host-libusb.c | 18 +++---
1 file changed, 1
Hi,
Just wanted to ping this. Patchwork link is here:
https://patchwork.kernel.org/project/qemu-devel/patch/20210201213021.500277-1-rosbro...@ainfosec.com/.
Thanks,
NR
On Mon, Feb 1, 2021 at 4:30 PM Nick Rosbrook wrote:
>
> In order to keep track of the alternate setting that should b
On Thu, Feb 18, 2021 at 12:52:51PM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 11, 2021 at 11:05:41AM -0500, Nick Rosbrook wrote:
> > Hi,
> >
> > Just wanted to ping this. Patchwork link is here:
> > https://patchwork.kernel.org/project/qemu-devel/patch/202
Fix building on NetBSD/arm by extracting the FSR value from the
correct siginfo_t field.
Signed-off-by: Nick Hudson
---
accel/tcg/user-exec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 52359949df..3637626456 100644
--- a
Fix building on NetBSD/arm by extracting the FSR value from the
correct siginfo_t field.
Signed-off-by: Nick Hudson
---
accel/tcg/user-exec.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 52359949df
Fix qemu build on NetBSD/evbarm-aarch64 by providing a NetBSD specific
cpu_signal_handler.
Signed-off-by: Nick Hudson
---
accel/tcg/user-exec.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 4be78eb9b3
Fix qemu build on NetBSD/evbarm-aarch64 by providing a NetBSD specific
cpu_signal_handler.
Signed-off-by: Nick Hudson
---
accel/tcg/user-exec.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index 4be78eb9b3
to get a sense
for where we are in the source code.
https://gist.github.com/nickdesaulniers/764ac9afab04775846ffa6c90c5a266a
If I rebuild QEMU from source, I don't get any disassembly that looks
similar, probably as a result of different compiler versions, and
maybe adding debug info.
--
Thanks,
~Nick Desaulniers
> On 29 Jun 2021, at 10:49, Peter Maydell wrote:
>
> On Tue, 29 Jun 2021 at 09:27, wrote:
>>
>> Signed-off-by: Nick Hudson
>> ---
>> target/arm/helper.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/arm
Signed-off-by: Nick Hudson
---
target/arm/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index a66c1f0b9e..7267af7924 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6330,7 +6330,7 @@ static const ARMCPRegInfo
> On 29 Jun 2021, at 12:50, Peter Maydell wrote:
>
> On Tue, 29 Jun 2021 at 11:41, Nick Hudson wrote:
>>
>>
>>
>>> On 29 Jun 2021, at 10:49, Peter Maydell wrote:
>>>
>>> On Tue, 29 Jun 2021 at 09:27, wrote:
>>>>
>
> On 29 Jun 2021, at 12:50, Peter Maydell wrote:
>
> On Tue, 29 Jun 2021 at 11:41, Nick Hudson wrote:
>>
>>
>>
>>> On 29 Jun 2021, at 10:49, Peter Maydell wrote:
>>>
>>> On Tue, 29 Jun 2021 at 09:27, wrote:
>>>>
>
Hi,
Here are the required changes to allow qemu to emulate NetBSD/hppa.
Nick Hudson (2):
Implement the pcxl and pcxl2 Fast TLB Insert instructions as used by
NetBSD (and OpenBSD)
Always return EXCP_DMAR for protection id trap as EXCP_DMP is
considered legacy.
target/hppa
Always return EXCP_DMAR for protection id trap as EXCP_DMP is considered legacy.
"In PA-RISC 1.1 (Second Edition) and later revisions, processors must
use traps 26, 27,and 28 which provide equivalent functionality"
Signed-off-by: Nick Hudson
---
target/hppa/mem_helper.c | 3 +--
1 fi
Implement the pcxl and pcxl2 Fast TLB Insert instructions as used by NetBSD
(and OpenBSD)
See
https://parisc.wiki.kernel.org/images-parisc/a/a9/Pcxl2_ers.pdf
page 13-9 (195/206)
Signed-off-by: Nick Hudson
---
target/hppa/insns.decode | 3 +++
target/hppa/translate.c | 54
From: Nick Hudson
See
https://parisc.wiki.kernel.org/images-parisc/a/a9/Pcxl2_ers.pdf
page 13-9 (195/206)
Signed-off-by: Nick Hudson
---
target/hppa/insns.decode | 3 +++
target/hppa/translate.c | 52
2 files changed, 55 insertions(+)
diff
From: Nick Hudson
Here are the required changes to allow qemu to emulate NetBSD/hppa.
v2 changes:
- remove old debug code
Nick Hudson (2):
Implement the pcxl and pcxl2 Fast TLB Insert instructions as used by
NetBSD (and OpenBSD)
Always return EXCP_DMAR for protection id trap as
From: Nick Hudson
"In PA-RISC 1.1 (Second Edition) and later revisions, processors must use
traps 26, 27,and 28 which provide equivalent functionality"
Signed-off-by: Nick Hudson
---
target/hppa/mem_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/t
v3 changes:
- Don't use C99 comments and fix a typo in the comment
v2 changes:
- remove old debug code
*** BLURB HERE ***
Nick Hudson (2):
Implement the pcxl and pcxl2 Fast TLB Insert instructions as used by
NetBSD (and OpenBSD)
Always return EXCP_DMAR for protection id tr
From: Nick Hudson
See
https://parisc.wiki.kernel.org/images-parisc/a/a9/Pcxl2_ers.pdf
page 13-9 (195/206)
Signed-off-by: Nick Hudson
---
target/hppa/insns.decode | 3 +++
target/hppa/translate.c | 52
2 files changed, 55 insertions(+)
diff
1 - 100 of 114 matches
Mail list logo
