From: Carl Allendorph
The current code for QEMUMonitorProtocol accepts both a unix socket
endpoint as a string and a tcp endpoint as a tuple. Most of the scripts
that use this class don't massage the command line argument to generate
a tuple. This patch refactors qmp-shell slightly to reus
From: Carl Allendorph
I've created a patch for bug #1612908. The current docs for the scripts
in the "scripts/qmp/" directory suggest that both unix sockets and
tcp endpoints can be used. The TCP endpoints don't work for most of the
scripts, with notable exception of &#x
ain-search "example.com", "sales.example.com",
"eng.example.com";
I would expect the syntax to look like this:
qemu -hda 1.qcow2 -net nick -net
user,hostname=qemu,search=example.com,sales.example.com
--
Carl K
On Wed, May 11, 2011 at 6:01 AM, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
>> On Tue, May 10, 2011 at 6:40 PM, Carl Karsten wrote:
>>> I would expect the syntax to look like this:
>>>
>>> qemu -hda 1.qcow2 -net nick -net
>>> user,ho
o the prompt.
vmware-player runs wc-2.4.iso ok and I just put wc-2.4.img on a usbstick and a
real machine booted just fine.
So the qemu problem isn't stopping anything real. It just seems like something
that should be looked into. It could be a problem with qemu.
Carl K
Carl Karsten wrote:
Now for a bug report:
[EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio
whoops -
[EMAIL PROTECTED]:~/qemu$ qemu | grep -i version
QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard
I think I am running:
qemu-snapshot-2007
Carl Karsten wrote:
Carl Karsten wrote:
Now for a bug report:
[EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio
I'll try again with the current one.
just built/installed qemu-snapshot-2007-04-16_05
[EMAIL PROTECTED]:~/qemu$ ls -l $(which qemu)
-rwxr-xr-x 1
From 310902d2ccd88ccb8de971d0d7ede0dbc93939f4 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Sat, 10 Aug 2024 15:09:39 -0700
Subject: [PATCH] target/sparc: emulate floating point queue when raising
fp traps
Sparc 32-bit machines perform floating point operations in an
asynchronous co
From 9265233081fae546c0459792598a9f1688ddb020 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Sat, 10 Aug 2024 15:09:39 -0700
Subject: [PATCH v2] target/sparc: emulate floating point queue when
raising fp
traps
Sparc 32-bit machines perform floating point operations in an
asynchronous co
OK, I think the problem is the handling of dc->fsr_qne in
trans_STDFQ, lines 4583 and 4593 -- the code is evaluating
dc->fsr_qne at translation time and not at runtime.
On 8/16/24 14:19, Carl Hauser wrote:
Hi Richard,
I applied
ul, I could share a disk image with Solaris,
gnu tools, the test examples, etc. It's under 500MB compressed
and I think I have enough google drive space to accommodate that
at the moment.
--
Carl
On 8/16/24 00:23, Richard Hender
appening.
On 8/16/24 15:05, Richard Henderson
wrote:
On
8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of
dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code
is evaluating dc->fsr_qne at translation t
we've seen before that linux is blissfully
unaware of the floating point queue.
-- Carl
On 8/16/24 15:05, Richard Henderson
wrote:
On
8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of
dc->fsr_qne in tra
I changed target.c:4597 from return true; to return
advance_pc(dc); and it worked.
On 8/16/24 17:16, Richard Henderson
wrote:
On
8/17/24 09:48, Carl Hauser wrote:
netbsd panics in the kernel trap handler;
unfortunately it does
I changed translate.c:4597 from return true; to return
advance_pc(dc); and it worked.
On 8/16/24 17:16, Richard Henderson
wrote:
On
8/17/24 09:48, Carl Hauser wrote:
netbsd panics in the kernel trap handler;
unfortunately it does not
From f155cbd57b37fa600c580ed30d593f47383ecd38 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Fri, 16 Aug 2024 09:20:36 -0700
Subject: [PATCH] hw/char: suppress sunmouse events with no changes
Sun optical mice circa 1993 were based on the Mouse Systems
Corp. optical mice. The technical manual
k that the
keyboard should be done at the same time.
I'll wait on a V2 patch with the equality fix for a decision
about migration/vs new style.
-- Carl
On 8/20/24 00:34, Richard Henderson
wrote:
On
8/20/24 09:18, Carl Hauser wrote:
@@
Do you want me to submit a patch set fixing this or will you?
-- Carl
On 8/18/24 19:42, Richard Henderson
wrote:
On
8/18/24 10:03, Carl Hauser wrote:
I changed translate.c:4597 from return
true; to return advance_pc(dc); and it
On 9/9/24 11:07, Richard Henderson
wrote:
Changes for v5:
- Fix stdfq advance_pc.
r~
Carl Hauser (2):
target/sparc: Add FQ and FSR.QNE
target/sparc: Populate sparc32 FQ when raising fp exception
Richard Henderson (3):
target/sparc: Add FSR_QNE to
-2016 Fabrice Bellard and the QEMU Project developers
--
Carl K
format explicitly to remove the restrictions.
qemu-system-x86_64: -drive file=boot.img,bootindex=1: Block format 'raw'
does not support the option 'bootindex'
Is there a "yes you do --force" option ?
On Sun, May 7, 2017 at 9:02 PM, Thomas Huth wrote:
> On 07.
mu-system-x86_64: Initialization of device ide-hd failed: Device
initialization failed.
--
Carl K
On Mon, May 8, 2017 at 3:51 AM, Markus Armbruster wrote:
> Carl Karsten writes:
>
> > juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive
> > file=disk.cow -drive file=boot.img
> > WARNING: Image format was not specified for 'boot.img&#
On Mon, May 8, 2017 at 2:57 AM, Thomas Huth wrote:
> On 08.05.2017 06:22, Carl Karsten wrote:
> > neat. missed that.
> >
> > except it doesn't work.
> >
> > juser@gator:~/temp$ qemu-system-x86_64 -drive
> > file=boot.img,format=raw,bootindex=1
> &g
On Mon, May 8, 2017 at 10:32 AM, John Snow wrote:
>
>
> On 05/08/2017 10:15 AM, Carl Karsten wrote:
> > On Mon, May 8, 2017 at 3:51 AM, Markus Armbruster
> wrote:
> >
> >> Carl Karsten writes:
> >>
> >>> juser@gator:~/temp$ qemu-system-x86
On Mon, May 8, 2017 at 11:29 AM, Eric Blake wrote:
> On 05/08/2017 10:56 AM, Carl Karsten wrote:
>
> >>>>> juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses
> -drive
> >>>>> file=disk.cow -drive file=boot.img
> >>>>> WAR
Public bug reported:
Hi,
I'm using origin/master [60ac13...]. When I run any of the commands
in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that
it can connect to a QEMU instance by passing either a path to a unix
socket or a tcp endpoint in the format "host:port". The unix
Hello All,
I'm working on a new microcontroller target (Atmel ATSAM4E) for the
qemu-system-arm executable. I've successfully setup a machine and created
some peripherals. I have some questions about how to structure the files
for contributing this target to the qemu project.
In the current "hw"
On Mon, Aug 15, 2016 at 3:18 AM, Peter Maydell
wrote:
> This broadly matches the directory arrangement principles used
> by the Linux kernel sources, which is where we've borrowed it from.
>
Ok - I'll pursue the current directory structure.
Thanks,
~C
** Attachment added: "Used with other VNC servers.jpg"
https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982277/+files/Used%20with%20other%20VNC%20servers.jpg
** Description changed:
Description of problem
-
In my latest topic, I reported a bug relate to
** Attachment added: "Used with QEMU.jpg"
https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982276/+files/Used%20with%20QEMU.jpg
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Titl
Public bug reported:
Description of problem
-
In my latest topic, I reported a bug relate to QEMU's websocket:
https://bugs.launchpad.net/qemu/+bug/1718964
It has been fixed but someone mentioned that he met the same problem when using
QEMU with a standalone websocket pro
Public bug reported:
Description of problem
-
When VNC is connected to QEMU via websocket over a low speed network
(e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer
update, the VNC Client will get stuck, the cursor is almost impossible
to move, which may
Let me know if you have any suggestions or concerns.
>
Is there any reason why you chose to invent an interface for the flash
chip which is more complicated than the interface used by common flash
chips out there?
Maybe some EFI requirement?
Regards,
Carl-Daniel
that problem.
(SPI flash is an exception, but it uses out-of-band access anyway,
usually via some southbridge interface, and that means the IO vs.
execution conflict won't happen there either.)
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
st flash is probably using SPI nowadays
because the reduced PCB footprint can save lots of money. And for SPI
you only need OOB access for write and the memory region itself is readonly.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
be a case where deviation from real hardware
> emulation could better serve the VM's needs.
>
If we have to write the code anyway, and if it can work just fine with
current KVM/Qemu, is there a reason not to use the same interface as
real hardware?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Auf 10.03.2011 22:55, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
> wrote:
>
>> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>>
>>> I have documented a simple flash-like device which I think could be
>>> useful for
Auf 10.03.2011 23:14, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
> wrote:
>
>> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>>
>>> I thought this might be a case where deviation from real hardware
>>> emul
Auf 10.03.2011 23:58, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
> wrote:
>
>> Right, the constant size argument is definitely a point we need to talk
>> about.
>>
>> We could sidestep the issue by always using a 16 MByte
Hi Jordan,
thanks for your insights.
Auf 10.03.2011 23:29, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger
> wrote:
>
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>
>>> On Thu, Mar 10, 2011 at 13:37, Car
Auf 11.03.2011 01:19, Jan Kiszka schrieb:
> On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote:
>
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>
>>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>>> wrote:
>>>
>>>
in coreboot. Not sure if it is usable
for those purposes. coreboot uses it to generate AMD CPU frequency tables.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
d a binary blob.
>
>> Is the proper way described somewhere?
>>
>
> The proper way is to use a mailer that isn't broken. Attaching
> everything as "application/octet-stream" is broken.
Some mailers do the right thing if the attachment name ends in .txt
(m
x on all VIA chipsets without VGA
support (no VGA ROM, no VGA interface) and X works just fine. Note that
this works on pretty much every 2.6.x Linux kernel and X with the
Unichrome driver.
Regards,
Carl-Daniel
--
Developer quote of the month:
"We are juggling too many chainsaws and flaming arrows and tigers."
?
>>> Use "QEMU Project" or "QEMU Community" throughout for manufacturer
>>> name?
>> I'll change this to use defines as per Kevin's request, so to keep
>> number of defines to minimum
>> lets make it "QEMU Project" everywhere.
>
> Will you introduce something like CONFIG_SYSVENDOR? Would be useful in
> case some other project
> (Bochs, Xen?) starts to use seabios.
coreboot already uses SeaBIOS on various x86 hardware platforms.
Regards,
Carl-Daniel
--
Developer quote of the month:
"We are juggling too many chainsaws and flaming arrows and tigers."
state fully correct after a migration.
On Wed, Aug 21, 2024 at 7:18 AM Mark Cave-Ayland
wrote:
>
> On 20/08/2024 08:34, Richard Henderson wrote:
>
> > On 8/20/24 09:18, Carl Hauser wrote:
> >> @@ -959,6 +960,15 @@ static void sunmouse_event(void *opaque,
> >>
This still, but less frequently, shows the behavior of having the cursor
leap downwards occasionally. I may not be able to work on debugging it
until next week, but I'll try to see if I can figure it out sooner. The
hypothesis with the old code was that it was sending floods of mouse
messages and t
host events are propagating down to escc via calls to
sunmouse_sync. So is sunmouse_sync where they should be filtered out?
Probably, because the calling code is not specific to sunmouse and for
other mice those calls are needed.
-- Carl
On Mon, Sep 2, 2024 at 4:16 PM Carl Hauser wrote:
> Th
This works well.
On Tue, Sep 3, 2024 at 1:38 PM Mark Cave-Ayland <
mark.cave-ayl...@ilande.co.uk> wrote:
> Update the Sun mouse implementation to use QemuInputHandler instead of the
> legacy qemu_add_mouse_event_handler() function.
>
> Note that this conversion adds extra sunmouse_* members to ES
on the whole
> disk, offset must be 0
> flag BIG_REQUEST is set and length > 0->request on
> (offset*block_size, length*block_size), length*block_size must be <=
> disk_size
What happens if length*block_size<=disk_size, but
offset*block_size+length*block_size>disk_size? Wraparound?
Regards,
Carl-Daniel
51 matches
Mail list logo
