apparently it was always blocking, the patch doesn't make the
> situation any worse. I'll apply it for 9.2.
Thank you.
Jakub
o I'm not sure if sftp_aio_*() can be combined with something else into
> > > a working solution, and I also don't know if it's affected by the same
> > > libssh bug.
> >
> > Right now, we do not have a full solution. But having SFTP working
> >
Hello,
comments inline below.
On Thu, Nov 14, 2024 at 4:21 PM Kevin Wolf wrote:
> [...]
>
> > I'll just note that I'm only forwarding on the patch from Jakub.
> > I didn't write it.
> >
> > I did lightly test it, and it seems to work. However it see
On Sat, 02 Nov 2024 16:52:17 -0500 David Woodhouse wrote:
> From: David Woodhouse
>
> The VMCLOCK device gives support for accurate timekeeping even across
> live migration, unlike the KVM PTP clock. To help ensure that users can
> always use ptp_vmclock where it's available in preference to ptp
On Sat, 19 Oct 2024 18:49:24 +0100 David Woodhouse wrote:
> > Yes please and thank you! We gotta straighten it out before
> > the merge window.
>
> Hm, as I (finally) come to do that, I realise that many of the others
> defined in drivers/ptp/Kconfig are also 'default y'. Which is only
> really
On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
> On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > > +config PTP_1588_CLOCK_VMCLOCK
> > > + tristate "Virtual machine PTP
On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> +config PTP_1588_CLOCK_VMCLOCK
> + tristate "Virtual machine PTP clock"
> + depends on X86_TSC || ARM_ARCH_TIMER
> + depends on PTP_1588_CLOCK && ACPI && ARCH_SUPPORTS_INT128
> + default y
Why default to enabled? Linus wil
On Fri, 26 Jul 2024 13:28:17 +0100 David Woodhouse wrote:
> +` status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
^ watch out for ticks!
On Sun, 31 Mar 2024 16:20:30 -0400 Michael S. Tsirkin wrote:
> > Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
> > Cc: sta...@vger.kernel.org
>
> net has its own stable process, don't CC stable on net patches.
Not any more, FWIW:
1.5.7. Stable tree
While it used
On 6/17/21 12:09 PM, Klaus Jensen wrote:
On Jun 17 12:08, Klaus Jensen wrote:
From: Klaus Jensen
Jakub noticed[1] that, when using pin-based interrupts, the device will
unconditionally deasssert when any CQEs are acknowledged. However, the
pin should not be deasserted if other completion
On 6/14/21 8:19 PM, Klaus Jensen wrote:
On Jun 14 15:54, Jakub Jermář wrote:
An IRQ vector used by a completion queue cannot be deasserted without
first checking if the same vector does not need to stay asserted for
some other completion queue. To this end the controller structure is
extended
for completion queues that are
asserted repeatedly, each completion queue is extended by a flag which
tells whether the queue is currently asserted.
Signed-off-by: Jakub Jermar
---
hw/nvme/ctrl.c | 22 --
hw/nvme/nvme.h | 2 ++
2 files changed, 18 insertions(+), 6 deletions
On 6/10/21 8:14 PM, Klaus Jensen wrote:
On Jun 10 13:46, Jakub Jermář wrote:
An IRQ vector used by a completion queue cannot be deasserted without
first checking if the same vector does not need to stay asserted for
some other completion queue.
Signed-off-by: Jakub Jermar
---
hw/nvme/ctrl.c
An IRQ vector used by a completion queue cannot be deasserted without
first checking if the same vector does not need to stay asserted for
some other completion queue.
Signed-off-by: Jakub Jermar
---
hw/nvme/ctrl.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions
** Bug watch added: Debian Bug tracker #954266
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954266
** Also affects: qemu (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954266
Importance: Unknown
Status: Unknown
--
You received this bug notification because yo
On Wed, 27 Nov 2019 15:32:17 -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote:
> > On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:
> > > Note: This RFC has been sent to netdev as well as qemu-devel lists
> &
On Wed, 27 Nov 2019 10:59:37 +0800, Jason Wang wrote:
> On 2019/11/27 上午4:35, Jakub Kicinski wrote:
> > On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:
> >> Note: This RFC has been sent to netdev as well as qemu-devel lists
> >>
> >> This s
On Tue, 26 Nov 2019 19:07:26 +0900, Prashant Bhole wrote:
> Note: This RFC has been sent to netdev as well as qemu-devel lists
>
> This series introduces XDP offloading from virtio_net. It is based on
> the following work by Jason Wang:
> https://netdevconf.info/0x13/session.html?xdp-offload-with-
My gdb-fu isn't great - does the following help?
Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in
(dev=dev@entry=0x7161b6a0)
at audio/audio_template.h:304
304 audio/audio_template.h: No such file or directory.
(gdb) print (*dev)->driver
$1 = AUDIODEV_DRIVER_PA
(gdb) watc
Public bug reported:
After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release
tarball), I'm seeing a (reproducible) crash related to audio subsystem.
I recompiled qemu with debugging options and got it to crash under gdb:
Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted.
0x
On 5/19/19 5:16 PM, Aleksandar Markovic wrote:
>> From: Jakub Jermar
>>
>> On 5/19/19 2:00 PM, Aleksandar Markovic wrote:
>>>>>
>>>>> * A fix for HelenOS boot hang (related to the flag PAGE_EXEC)
>>>>
>>>> This was r
On 5/19/19 2:00 PM, Aleksandar Markovic wrote:
>>>
>>> * A fix for HelenOS boot hang (related to the flag PAGE_EXEC)
>>
>> This was rather a problem with failing non-executable page tests in
>> L4Re, not HelenOS. Even though I tested HelenOS for regressions
PAGE_EXEC in map_address (2019-05-19 12:11:46 +0200)
>
>
>
> MIPS queue for May 19th, 2019
>
> * A fix for HelenOS boot hang (related to the flag PAGE_EXEC)
This was rather a problem with failing non-executable page tests in
L4Re, not
On 5/16/19 10:35 PM, Pankaj Gupta wrote:
> Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch
> :)I don't feel that I have enough expertise to give the reviewed-by tag, but
> you can
take my acked-by + tested-by.
Acked-by: Jakub Staron
Tested-by: Jak
result, pages that have the XI bit set in the TLB and are accessed
for read/write, don't suddenly end up being executable.
Signed-off-by: Jakub Jermář
---
Changes since v2:
This is the same patch as v2, but rebased to current master.
target/mips/helper.c | 13 -
1 file ch
Hi Aleksandar and Philippe,
On 5/16/19 8:04 PM, Aleksandar Markovic wrote:
>
> On May 16, 2019 6:31 PM, "Philippe Mathieu-Daudé" <mailto:phi...@redhat.com>> wrote:
>>
>> Hi Jakub,
>>
>> On 5/16/19 3:10 PM, Jakub Jermar wrote:
>> > Hi,
Hi Philippe,
On 5/16/19 6:31 PM, Philippe Mathieu-Daudé wrote:
> Hi Jakub,
>
> On 5/16/19 3:10 PM, Jakub Jermar wrote:
>> Hi,
>>
>> On 5/3/19 12:02 PM, Jakub Jermar wrote:
>>> Hi,
>>>
>>> On 4/23/19 4:58 PM, Jakub Jermar wrote:
>>&g
Also attaching the 64-bit version of the reproducer.
** Attachment added: "64-bit version of the reproducer"
https://bugs.launchpad.net/qemu/+bug/1825311/+attachment/5264428/+files/reproducer64.tar.xz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
27;t
> + * do anything about that.
> + */
> + if (err || !err1) {
> + dev_info(&vdev->dev, "failed to send command to virtio pmem
> device\n");
> + err = -EIO;
> + } else {
> + /* A host repsonse results in "host_ack" getting called */
> + wait_event(req->host_acked, req->done);
> + err = req->ret;
> +I confirm that the failures I was facing with the `-ENOSPC` error path are
> not present in v9.
Best,
Jakub Staron
Hi,
On 5/3/19 12:02 PM, Jakub Jermar wrote:
> Hi,
>
> On 4/23/19 4:58 PM, Jakub Jermar wrote:
>> Hi Philippe!
>>
>> On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
>>> Hi Jakub,
>>>
>>> On 4/23/19 1:00 PM, Jakub Jerm
nt of the queue. In our case
(and also in the question's author case), `vpmem->req_list` is not element
of any request struct and not an element of the list. It's just a list head
storing
`next` and `prev` pointers which are then pointing to respectively first and
last element of the list. We want to unlink the first element of the list,
so we need to pass pointer to the first element of the list to
the `list_del` function - that is, the `vpmem->req_list.next`.
Thank you,
Jakub Staron
>wq_buf, req->wq_buf_avail);
spin_lock_irqsave(&vpmem->pmem_lock, flags);
}
+
+ /*
+* virtqueue_add_sgs failed with error different than -ENOSPC, we can't
+* do anything about that.
+*/
+ if (err) {
+ dev_info(&vdev->dev, "failed to send command to virtio pmem
device, error code %d\n", err);
+ spin_unlock_irqrestore(&vpmem->pmem_lock, flags);
+ err = -EIO;
+ goto ret;
+ }
err = virtqueue_kick(vpmem->req_vq);
spin_unlock_irqrestore(&vpmem->pmem_lock, flags);
Let me know if it looks reasonable to you.
Thank you,
Jakub Staron
her `return !(vma->vm_flags & VM_SYNC);`? There is
no field named `flags` in `struct vm_area_struct`.
Thank you,
Jakub
Hi,
On 4/23/19 4:58 PM, Jakub Jermar wrote:
> Hi Philippe!
>
> On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
>> Hi Jakub,
>>
>> On 4/23/19 1:00 PM, Jakub Jermář wrote:
>>> This commit addresses QEMU Bug #1825311:
>>>
>>> mips_cpu_
I am attaching a reproducer image and script.
Unpatched execution ends like this:
...
TAP TEST START
1..2
not ok 1 NonExecutable::ElfDataIsNotExecutable
# Assertion failed
/home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:103
# Expected: -(L4_EIPC_LO + l4_ipc_error(tag, l4_u
Hi Philippe!
On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
> Hi Jakub,
>
> On 4/23/19 1:00 PM, Jakub Jermář wrote:
>> This commit addresses QEMU Bug #1825311:
>>
>> mips_cpu_handle_mmu_fault renders all accessed pages executable
>>
>> It allows
result, pages that have the XI bit set in the TLB and are accessed
for read/write, don't suddenly end up being executable.
Signed-off-by: Jakub Jermář
---
target/mips/helper.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/target/mips/helper.c b/target
result, pages that have the XI bit set in the TLB and are accessed
for read/write, don't suddenly end up being executable.
Signed-off-by: Jakub Jermář
---
target/mips/helper.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/target/mips/helper.c b/t
result, pages that have the XI bit set in the TLB and are accessed
for read/write, don't suddenly end up being executable.
Signed-off-by: Jakub Jermář
---
target/mips/helper.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/target/mips/helper.c b/target
Public bug reported:
On MIPS, data accesses to pages mapped in the TLB result in
mips_cpu_handle_mmu_fault() marking the page unconditionally executable,
even if the TLB entry has the XI bit set. Later on, when there is an
attempt to execute this page, no exception is generated, even though
TLBXI
As for the other outcome, when the guest hangs (instead of QEMU
crashing), the guest CPUs that block forward progress are halted in an
idle loop, have interrupts enabled and have a queued timer IRQ 248 and a
pending software IPI IRQ 250. It appears another timer IRQ is currently
being serviced (but
** Attachment added: "Debug binary with symbols"
https://bugs.launchpad.net/qemu/+bug/1811244/+attachment/5229552/+files/qemu-system-i386.xz
** Description changed:
When MTTCG is enabled, QEMU 3.1.0 sometimes crashes when running the
following command line:
qemu-system-i386 -kernel
** Attachment added: "coredump"
https://bugs.launchpad.net/qemu/+bug/1811244/+attachment/5229551/+files/qemu-system-i386.core.xz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1811244
Title:
qem
Public bug reported:
When MTTCG is enabled, QEMU 3.1.0 sometimes crashes when running the
following command line:
qemu-system-i386 -kernel
/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/bootstrap
-append bootstrap -initrd
"/home/jermar/work/software/l4/fiasco/.build-i386/fiasco
-ser
Public bug reported:
When negotiating virtio-net feature bits, the device ignores the absence
of the VIRTIO_NET_F_CTRL_VQ bit in driver feature bits and provides
three virtqueues, including the control virtqueue, even though the
driver is expecting only the receive and transmit virtqueues. Looking
on of the TLB Modified
exception suggests there indeed is such an entry in the TLB and only
requires its dirty bit to be set.
The operating system which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on
eptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on which this is reproducible is QEMU 1.4.0 and also
some others.
When I looked into the QEMU sources, I noticed the following
discrepancy, which could potentially explain the behavio
res its dirty bit to be set.
The operating system which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on which this is reproducible is QEMU 1.4.0 and also
some others.
When I looked into the QEMU sources, I n
better option?
I'd strongly prefer the option to build QEMU's own binaries and
distribute them in pc-bios/. Downloading this 190M tarball is a nuisance
and depending on their continued existence on the Oracle server is a risk.
Where does the dependency on Solaris 9 come from? You should be able to
run unmodified Solaris 9 binaries on eg. Solaris 10...
Best,
Jakub
Initialization of a class instance cannot depend on its own properties
as these are not yet set. Move parts of integratorcm_init() that depend
on the "memsz" property to the newly added integratorcm_realize().
This fixes: https://bugs.launchpad.net/qemu/+bug/1624726
Signed-off-by: Ja
On 09/20/2016 07:34 PM, Peter Maydell wrote:
> On 19 September 2016 at 20:54, Jakub Jermář wrote:
>>
>> * Do not assume memsz is already initialized in integratorcm_init
>> * Calculate memsz directly from MachineState
>> * Get rid of the now unused memsz property
>&g
* Do not assume memsz is already initialized in integratorcm_init
* Calculate memsz directly from MachineState
* Get rid of the now unused memsz property
Signed-off-by: Jakub Jermar
---
hw/arm/integratorcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm
Turns out integratorcm_init() depends on the memsz property being
already set, but that unfortunately is not the case as setting of memsz
depends on integratorcm_init() having completed:
dev = qdev_create(NULL, TYPE_INTEGRATOR_CM);<= calls
integratorcm_init(), needs memsz
qdev
** Bug watch added: Email to helenos-devel@lists #
mailto:helenos-de...@lists.modry.cz
** Also affects: helenos via
mailto:helenos-de...@lists.modry.cz
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is sub
Public bug reported:
The following command line no longer works (i.e. the guest does not
boot) with QEMU 2.7.0:
qemu-system-arm -M integratorcp -m 128M -kernel
HelenOS-0.6.0-arm32-integratorcp.boot
The HelenOS image can be downloaded here:
http://www.helenos.org/releases/HelenOS-0.6.0-arm32
Hello,
David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Jun 03, 2016 at 05:45:49PM +0200, Jakub Horak wrote:
> > Hello,
> > I think there's a bug in "wait" instruction code generator for PowerPC
> > architecture. It doesn't make sense to store
Hello,
I think there's a bug in "wait" instruction code generator for PowerPC
architecture. It doesn't make sense to store a non-initialized register.
Best regards,
Jakub Horak
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index f5ceae5..6af567b 100
d here.
"Never use this function. Use mkstemp(3) or tmpfile(3) instead."
--
Jakub Wilk
For me the icon looks ugly if QEMU is run by the normal user. However,
when run via sudo, it looks normal for some reason and does not display
any of the white pixels.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
It may be actually easier to start with recreating the Ski machine
inside QEMU. The result will be a faster Ski in a maintained codebase.
Definitely not a bad start.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
Yes, the patch fixes the problem for me. Thank you.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1359930
Title:
[ARMv5] Integrator/CP regression when reading FPSID register
Status in Home for var
** Summary changed:
- [ARMv5] Integrator/CP regression when reading FPSID instruction
+ [ARMv5] Integrator/CP regression when reading FPSID register
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1359
Public bug reported:
There seems to be a regression in QEMU 2.1.0 which demonstrates itself
when running the attached HelenOS Integrator/CP (i.e. ARMv5) image. The
offending instruction seems to be:
vmrs r0, fpsid
Upon its execution, HelenOS kernel receives an Undefined instruction
exception (
Here is the respective HelenOS kernel with debug symbols.
** Attachment added: "HelenOS kernel with debug symbols"
https://bugs.launchpad.net/helenos/+bug/1359930/+attachment/4183966/+files/kernel.raw
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
not anticipate at that point) and crashes.
QEMU 2.0.0 was not affected by this issue.
Any ideas what may have gone wrong? If needed, I can provide a test binary.
Please Cc me directly in your reply as I am not subscribed to qemu-devel@
Thanks,
Jakub
I think I am seeing the same symptoms when I let two QEMU instances talk
to each other over pipe serial.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1181796
Title:
Qemu locks up when incoming ser
Guys, perhaps we should move this dialogue to a different thread as we
are abusing the unrelated Bug 1128935.
Jakub
On 04/06/2013 07:01 PM, blueswirl wrote:
> On Sat, Apr 6, 2013 at 9:31 AM, agraf <1128...@bugs.launchpad.net> wrote:
>> Hi Lurie,
>>
>> On 04.04.
uld u
> accept such a student to make this project?
I can't speak for QEMU as I am from the HelenOS mentoring organization,
but according to how GSoC works, a student is free to suggest any
project. The organizations will then pick the best student applications
for things they like and can p
em which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on which this is reproducible is QEMU 1.4.0 and also
some others.
When I looked into the QEMU sources, I noticed the following
discrepancy, which could pot
requires its dirty bit to be set.
The operating system which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on which this is reproducible is QEMU 1.4.0 and also
some others.
When I looked into the QEMU so
its dirty bit to be set.
The operating system which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU version on which this is reproducible is QEMU 1.4.0 and also
some others.
When I looked into the QEMU sources, I noticed the
, because the invocation of the TLB Modified
exception suggests there indeed is such an entry in the TLB and only
requires its dirty bit to be set.
The operating system which can trigger and is susceptible to this
behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
The QEMU
834
0xbfc00820: nop
0xbfc00824: jal 0xbfc00870
0xbfc00828: nop
0xbfc0082c: b 0xbfc00814
I verified the print subroutine works as expected with the fix.
Please find the fix attached to this message.
Regards,
Jakub
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index dfd7
On 20.4.2012 12:17, Jakub Jermar wrote:
> I am observing an interesting phenomenon on the latest QEMU git and the
> latest HelenOS mainline (the problem is likely guest-neutral though).
> The QEMU command line is as follows:
>
> $ qemu-system-i386 -device rtl8139,vlan=0 -net user
]
There is a HelenOS ticket for this also:
http://trac.helenos.org/ticket/442
Is this a known SLIRP issue or am I missing something important here?
Jakub
ed if it was correct for all
>>> architected variants.
>>
>> Well the original value above hasn't changed from Alex's original
>> commit (I simply augmented the comment), and it agrees with my reading
>> of the specification pages as directed by Alex. Given that we also
>> agreed to minimise the impact of the patch by making the least amount
>> of changes (and it works for my HelenOS tests while preserving the
>> existing behaviour), do you still think it makes sense to change the
>> whole MSR calculation in this way?
>
> Does HelenOS break without the patch? It worked fine for me.
Hi Alex,
I've just tested QEMU git (which includes the TLB invalidation fix) and
it seems to work with HelenOS mainline quite nice. Not sure if we can
conclude the other fix is not needed though.
Jakub
ed if it was correct for all
>>> architected variants.
>>
>> Well the original value above hasn't changed from Alex's original
>> commit (I simply augmented the comment), and it agrees with my reading
>> of the specification pages as directed by Alex. Given that we also
>> agreed to minimise the impact of the patch by making the least amount
>> of changes (and it works for my HelenOS tests while preserving the
>> existing behaviour), do you still think it makes sense to change the
>> whole MSR calculation in this way?
>
> Does HelenOS break without the patch? It worked fine for me.
Hi Alex,
I've just tested QEMU git (which includes the TLB invalidation fix) and
it seems to work with HelenOS mainline quite nice. Not sure if we can
conclude the other fix is not needed though.
Jakub
How to reproduce:
1. make sure openbios-ppc from Qemu 0.11.1 is installed
2. $ qemu-system-ppc -cdrom HelenOS-0.4.2-ppc32.iso -boot d
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/942299
Title:
Re
Public bug reported:
Mark Cave-Ayland identified Qemu commit
41557447d30eeb944e42069513df13585f5e6c7f as the first bad commit which
prevents HelenOS/ppc from booting with OpenBIOS taken from Qemu 0.11.1.
Note that we deliberately use the OpenBIOS from Qemu 0.11.1 because
there is another suspecte
** Tags added: ia64-softmmu itanium qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/917645
Title:
[Feature request] ia64-softmmu wanted
Status in Home for various HelenOS development branches:
Public bug reported:
Qemu is missing support for full system emulation of the Itanium
architecture, which is one of the main non-x86 server architectures
today (despite the alleged decline in popularity). It would be really
nice if someone had interest in adding full ia64 support to Qemu. Many
OS
,
Jakub
On 1.7.2011 16:24, Laurent Desnogues wrote:
> On Fri, Jul 1, 2011 at 4:11 PM, Jakub Jermar wrote:
> [...]
>> Actually, the testcase can be further reduced into:
>>
>> .global _start
>>
>> .text
>>
>> .space 0x20
>>
>> _start:
>>
r me is via GDB's stepi.
Jakub
On 1.7.2011 14:57, Jakub Jermar wrote:
> On 1.7.2011 12:41, Artyom Tarasenko wrote:
>> Looks like it's a pretty nice test case.
>>
>> The test case scenario is to load the initial values into the
>> registers (you already know them),
>> calculate the mins,
mu-system-sparc64 -bios ./testcase
With GDB:
$ qemu-system-sparc64 -bios ./testcase -s -S
>From another terminal:
$ /usr/local/cross/sparc64/bin/sparc64-linux-gnu-gdb
(gdb) set architecture sparc:v9
(gdb) target remote localhost:1234
(gdb) stepi
...
Hope this helps to fix the problem.
Jakub
.P
Hi Artyom,
On 1.7.2011 11:15, Artyom Tarasenko wrote:
> Hi Jakub,
> 2011/6/30 Jakub Jermar :
>> Hi,
>>
>> we have been observing a problem with HelenOS running on the latest git
>> Qemu/sparc64. The gist of the problem is that the following computation
>> o
ion of qemu.log with some comments and pointers in it.
I would appreciate if someone who understands the sparc64 code
translation could have a look at this. More debugging data may be
provided upon request.
Thanks,
Jakub
IN:
0x67a4: ldub [ %o0 + 0xb ], %g1
0x67a8: sub %i
d is fixed or not. The key map which we
originally
used was reverse engineered from the old Qemu. Now it looks like we
will simply
dump it and use the PC keyboard for it.
Thanks for making this clear.
Jakub
This message was
Quoting Peter Maydell :
On 21 March 2011 23:03, Jakub Jermar wrote:
I noticed that the layout of the PL050 keyboard used on Integrator/CP
incompatibly changed sometime between Qemu 0.10.5 and Qemu 0.11.1. The
current layout used in Qemu's model of Integrator/CP is the standard PC
layout.
Does
anybody know what was the motivation for that change?
Thanks,
Jakub
without kvm, both on ia32 and
amd64 hosts.
Any idea appreciated.
Regards,
Jakub
n assume that it's all
> in-process, and hence all _within_ qemu, and we could actually implement
> the futex stuff entirely within qemu with qemu's own locking?
>
> For now I think the safer option is just to leave FUTEX_WAKE_OP
> unimplemented. Jakub, what do you
r for including full sparc64 support in
qemu releases?
Thanks for your answer and please respond directly to me as I don't read
qemu-devel.
Cheers,
Jakub
94 matches
Mail list logo
