Ken,
Lookup starting the gvncviewer tool after you start the virtual machine. To
get the display for the VMs I run gvncviewer and sometimes spicec.
Don
Kenneth Adam Miller wrote on 9/7/24 4:58 PM:
Hello,
I've got qemu built and now I need to figure out how to run it with what I've
got.
ot;);
if (vms->dtb_randomness) {
+1 to Peter's suggested comment, otherwise, unless privy to this thread,
one would wonder how/why.
Reviewed-by: Donald Dutile
Public bug reported:
The output for the "-cpu help" on the Sparc executables is not
generating accurate information.
Running
./qemu-sparc64 -cpu help
produces:
Sparc Fujitsu Sparc64 IU 00040002 FPU MMU NWINS 4
Sparc Fujitsu Sparc64 III IU 00040003 FPU 000
Do I need to repost with the 2 Reviewed-by ?
-Don Slutz
On 10/06/14 05:26, Richard W.M. Jones wrote:
> On Fri, Oct 03, 2014 at 05:33:37PM -0400, Don Slutz wrote:
>> From: "Dr. David Alan Gilbert"
>>
>> This is a pc & q35 only machine opt.
>>
>> VMWare apparently doesn't like running under QEM
On 09/30/14 06:35, Stefano Stabellini wrote:
> On Mon, 29 Sep 2014, Don Slutz wrote:
>> On 09/29/14 06:25, Stefano Stabellini wrote:
>>> On Mon, 29 Sep 2014, Stefano Stabellini wrote:
On Fri, 26 Sep 2014, Don Slutz wrote:
> This adds synchronisation of the vcpu registers
> between Xen
On 09/25/14 11:07, Dr. David Alan Gilbert wrote:
> * Slutz, Donald Christopher (dsl...@verizon.com) wrote:
>> What is happening with this patch? I would like to use this code.
> I need to rework it for the new machine types code; but it was pretty
> low down my list of priorities
What is happening with this patch? I would like to use this code.
-Don Slutz
From: qemu-devel-bounces+don=cloudswitch@nongnu.org
[qemu-devel-bounces+don=cloudswitch@nongnu.org] on behalf of Gerd Hoffmann
[kra...@redhat.com]
Sent: Tuesday, May
On 06/24/14 22:49, Chen, Tiejun wrote:
> On 2014/5/19 19:22, Gerd Hoffmann wrote:
>> Hi,
>>
>>> I think '-vga none' just guarantees the qemu vga cards doesn't occupy
>>> 00:02.0, but this doesn't mean others use this specific slot since in
>>> qemu internal, we always pass -1 to assign a slot aut
So how the commit message change:
On 06/25/14 16:19, Don Slutz wrote:
> This will prevent correct migration from QEMU 1.7.0 for these
> machine types when -m 3.5G is specified.
This fixes bug:
https://bugs.launchpad.net/qemu/+bug/1334307
> Paolo Bonzini asked that:
>
> smbios_le
On 06/17/14 16:17, Michael S. Tsirkin wrote:
> On Tue, Jun 17, 2014 at 04:08:54PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jun 17, 2014 at 10:43:29PM +0300, Michael S. Tsirkin wrote:
[snip]
>> I think he mentioned PCI devices, not PCIe.
> OK that's a small niche but it makes some sense.
> So
I've just this week begun using qemu (actually qemu-kvm) on a 64-bit
Slackware (13.37) system. You people have produced a very useful piece of
software, very nice work. But I must say that the documentation does not do
the software justice. I have just spent a maddening several hours trying to
get
m?
>
>
> Thank you
>
--
Regards,
Donald Wang
Need to check that guest slot/device number is not > 31 or walk off
the devfn table when checking if a devfn is available or not in a guest.
before this fix, passing in an addr=abc or addr=34,
can crash qemu, sometimes fail gracefully if data past end
of devfn table fails the availability test.
于Mon 12 Sep 2011 03:59:07 PM CST,Kevin Wolf写到:
Am 10.09.2011 02:54, schrieb Dong Xu Wang:
于Fri 09 Sep 2011 10:27:26 PM CST,Kevin Wolf写到:
Am 09.09.2011 07:48, schrieb Dong Xu Wang:
As raw file format does not support backing_file and copy on write feature, so
I add COW to it to support backing_
i see. you are right, thanks very much2006/10/8, Paul Brook <[EMAIL PROTECTED]>:
On Saturday 07 October 2006 19:15, Donald Liew wrote:> i'm reading qemu-system-arm code and trying to add some more> evaluation boards support for it. in the 0.8.2 source code i found> somethin
his, why? won't this cause problems like redundant
interrupts? any special consideration about this?
donald
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
We've seen multiple issues with tightVNC, mainly because I don't believe
that tightvnc does resize requests at all. Can you try a realvnc client
and see if you see the same issues?
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: (303)443-3786
>-Origina
Well, calling it worthless is a little harsh. As with all documentation
I'm sure it could be made better but, if you read the documentation
carefully, it actually tells you what to do.
Note that there are instructions on how to boot a CD image (section 3.3
of the user manual, check out the option
Is anybody working on creating an EHCI driver for the USB subsystem? I
have a need to access high speed devices and wanted to find out if I'd
be re-inventing the wheel before I start on this.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: (303)440-1368
__
ursday, May 11, 2006 4:48 PM
>To: qemu-devel@nongnu.org
>Subject: Re: [Qemu-devel] [PATCH]Fix for minor video
>corruption under Windows
>
>Hi,
>
>I think the proper fix must be done in the BIOS (set VRAM to 0xFF at
>cirrus mode init). I made a patch for that but I must test it
WD-
I see the problem here, `patch' got confused because my patch was
against a 0.8.0 tree and you applied it to a 0.8.1 tree. You wound up
making the change to `cirrus_hook_read_sr', where the Windows driver
attempts to read the mode register. The patch is supposed to apply to
the routine `cirr
E. Reiter
>Sent: Tuesday, May 09, 2006 2:29 PM
>To: qemu-devel@nongnu.org
>Subject: Re: [Qemu-devel] [PATCH]Fix for minor video
>corruption under Windows
>
>Donald...
>
>thanks... I actually posted a patch to fix this sometime ago, but your
>patch seems more thorough and pr
If you change the video resolution while running a Windows XP image such that
it uses fewer bytes of VRAM (either by using fewer bytes per pixel or by
lowering the resolution) then some window backgrounds will become corrupted.
This happens because the Windows XP Cirrus Logic driver assumes that VR
Interesting. You're right, the protocol explicitly says that both
`reset' and `set to default' are supposed to disable the mouse. I have
to admit, I was basing my patch on the fact that, in tracing the
commands I received from the X server, I saw a `reset' that was not
followed by an `enable'. I
While tracking down a problem with getting X to work with the VNC
version of Qemu I discovered a problem in the way the Qemu mouse
emulation was handling mouse reset commands. Turns out, the emulation
code is a little over aggressive in dealing with reset commands for the
mouse. Since there are c
25 matches
Mail list logo
