hi everyone :
Resently I used the QEMU to install XP system ,and the OS of my PC is XP
,too. but how to install the other software on the XP system which is on the
top of qemu? I have searched some methods through google ,like using USB, or
ISO , or FTP and so on , and there so many methods
On Nov 9, 2009, at 12:22 PM, Christoph Hellwig wrote:
On Mon, Nov 09, 2009 at 11:46:13AM -0700, C.W. Betts wrote:
Does this work?
diff --git a/configure b/configure
index aa2cc43..00e04e9 100755
--- a/configure
+++ b/configure
@@ -1060,7 +1060,11 @@ fi
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
> A simpler approach is to collect memory statistics in the virtio
> balloon driver and communicate them to the host via the device config space.
There are two issues I see with this. First, there's an atomicity problem
since you can't tell when t
I just patched and ran with two of the programs with from the parsec suite and
they both run with the small input sets. I will run the full suite later
tonight and let you know the results.
Thanks for the help,
David
- Original Message -
From: "Blue Swirl"
To: "David Munday"
Cc: qemu-
Jan Kiszka wrote:
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the build issues alread
Hollis Blanchard wrote:
> This is the technique Anthony requested this morning, rather than
> relocating mp_state.
Then let's move it. There is not that much code to share anyway.
> To be honest, I don't care which way it's fixed;
> this is at least the 3rd patch to solve this seemingly trivial
>
This is the technique Anthony requested this morning, rather than
relocating mp_state. To be honest, I don't care which way it's fixed;
this is at least the 3rd patch to solve this seemingly trivial
problem.
/home/hollisb/source/qemu-fresh.hg/kvm-all.c: In function 'kvm_put_mp_state':
/home/hollis
On 09.11.2009, at 23:12, Jan Kiszka wrote:
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the
Hollis Blanchard wrote:
> Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the build issues already in place, specifically as
On 11/09/09 21:38, Blue Swirl wrote:
As Michael notes, devices have physical address sizes independent of the
target platform; a PCI device that supports 64-bit addresses can be plugged
into a motherboard that supports 32-bit address bus processors.
True. But I think the solution is not to make
Jamie Lokier wrote:
Adam Litke wrote:
+s->stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ?
+ dev->stats.pswapin : -1;
(etc.)
Why not simply have the guest fill in the unused fields with -1, and
say that's how "no meaningfu
Unbreaks PowerPC and S390 KVM builds.
Signed-off-by: Hollis Blanchard
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state = { .mp_state = env->mp_state };
-
-
Signed-off-by: Hollis Blanchard
diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
--- a/target-ppc/kvm_ppc.c
+++ b/target-ppc/kvm_ppc.c
@@ -52,7 +52,6 @@ close:
fclose(f);
free:
free(path);
-out:
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe
Hi Anthony, please apply these two patches to fix the PowerPC KVM build.
-Hollis
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 9, 2009 at 2:37 PM, Avi Kivity wrote:
> On 11/09/2009 11:08 AM, Gerd Hoffmann wrote:
>>
>>> You are also moving the compilation to Makefile.hw, which is not
>>> exactly an improvement. Is this needed because of the QEMUIOVector
>>> stuff?
>>
>> Almost correct ;)
>>
>> It is because of
On 09.11.2009, at 20:44, Anthony Liguori wrote:
Alexander Graf wrote:
On 29.10.2009, at 22:39, Hollis Blanchard wrote:
On Wed, 2009-10-21 at 21:17 +0200, Alexander Graf wrote:
MP State is implemented in the generic code, so let's move the
variable
it accesses to generic code as well.
St
Alexander Graf wrote:
On 29.10.2009, at 22:39, Hollis Blanchard wrote:
On Wed, 2009-10-21 at 21:17 +0200, Alexander Graf wrote:
MP State is implemented in the generic code, so let's move the variable
it accesses to generic code as well.
Still unbreaks PPC and now even S390x w/ KVM.
Signed-o
Avi Kivity wrote:
> On 11/07/2009 12:44 PM, Jamie Lokier wrote:
> >Aiee - what's the plan? Can a running KVM be forked, as in into two
> >separate processes to run the forked guests in parallel, or not?
>
> kvm fds do not support fork(). Nothing prevents you from stopping the
> guest, reading g
On Mon, 2009-11-09 at 19:01 +, Jamie Lokier wrote:
> These days, would it make more sense to emit a QJSON object?
>
> In this case the JSON object is quite human readable too.
I'm not very particular on the output format since it's main consumer is
likely another program. Is XML output via t
Anthony Liguori wrote:
> You are correct except that I qualified this as NAT with host access
> which so far is the common model. If the host can access the NAT'd
> network behind the NAT, then port privileges are important.
You're right.
This is why QEMU guests should be run inside an LXC con
On Mon, 2009-11-09 at 19:00 +, Jamie Lokier wrote:
> Adam Litke wrote:
> > +s->stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT)
> > ?
> > + dev->stats.pswapin : -1;
>
> (etc.)
>
> Why not simply have the guest fill in the unused fi
This patch adds support for the new KVM IOCTLs KVM_GET/SET_VCPU_STATE.
They are supposed to be introduced with 2.6.33 or 34 and allow to extend
the VCPU state exchange between kernel and user space without adding new
IOCTLs and to acquire/set a complete state via a single systemcall.
In order to r
Adam Litke wrote:
> +static inline void print_stat(Monitor *mon, uint32_t val, const char *label)
> +{
> +if (val != -1) {
> +monitor_printf(mon, ",%s=%u", label, val);
> +}
> +}
> +
> static void do_info_balloon(Monitor *mon)
> {
> -ram_addr_t actual;
> +QEMUBalloonState
Adam Litke wrote:
> +s->stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ?
> + dev->stats.pswapin : -1;
(etc.)
Why not simply have the guest fill in the unused fields with -1, and
say that's how "no meaningful value" is represented in t
On Mon, Nov 02, 2009 at 03:06:45PM +0100, Alexander Graf wrote:
> Avi Kivity wrote:
> > On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
> >> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
> >>
> >>> On 11/02/2009 03:15 PM, Alexander Graf wrote:
> >>>
> They are taken with -d
Current .gitmodules contains:
[submodule "roms/vgabios"]
path = roms/vgabios
url = ../vgabios.git
[submodule "roms/seabios"]
path = roms/seabios
url = ../seabios.git
but these URLs don't work for me. They resolve to URLs like
git://git.savannah.non
On Monday 02 November 2009, Laurent Desnogues wrote:
> That indeed looks strange: fixing the TB chaining on ARM
> made nbench i386 three times faster. Note the gain was
> less for FP parts of the benchmark due to the use of
> helpers.
>
> out of curiosity could you post your tb_set_jmp_target1
>
On Monday 02 November 2009, Aurelien Jarno wrote:
> First of all I have a question about s390/s390x. It seems that you
> plan to support both s390 and s390x in the same file. Is that correct?
Actually, I didn't think about supporting s390 hosts at all, but it
should be possible.
> Do you know ho
Gerd Hoffmann wrote:
On 11/09/09 17:06, Paul Brook wrote:
On Tuesday 08 September 2009, Anthony Liguori wrote:
Gerd Hoffmann wrote:
$subject says pretty much everything.
extboot.[cS] are a straight copy from the kvm tree. The windup in
vl,c
and hw/pc.c is done slightly different, I've added
When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests. The current method
employs a daemon running in each guest that communicates memory st
On 11/09/09 17:06, Paul Brook wrote:
On Tuesday 08 September 2009, Anthony Liguori wrote:
Gerd Hoffmann wrote:
$subject says pretty much everything.
extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c
and hw/pc.c is done slightly different, I've added a function to lookup
t
On Friday 11 September 2009, Anthony Liguori wrote:
> malc wrote:
> > And generalizations are always true. Anyhow, i'm explicitly against the
> > patch, so first obtain the express acknowledgment from the leaders,
> > otherwise i'll revert it should it go in.
>
> I'm adding the following patch to
Changes since V1:
- In the monitor, print all stats on one line with less abbreviated names
- Coding style changes
When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact
On Tuesday 08 September 2009, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
> > $subject says pretty much everything.
> >
> > extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c
> > and hw/pc.c is done slightly different, I've added a function to lookup
> > the boot drive instea
Jamie Lokier wrote:
Anthony Liguori wrote:
Let's not kid ourselves, no matter what we do we're giving a user
elevated privileges. Even with NAT, if the host can access the NAT'ed
network, then you can run a privileged service (like NFS) in that
network.
I don't see how outgoing NAT
Anthony Liguori wrote:
> Let's not kid ourselves, no matter what we do we're giving a user
> elevated privileges. Even with NAT, if the host can access the NAT'ed
> network, then you can run a privileged service (like NFS) in that
> network.
I don't see how outgoing NAT (SNAT), where the guest
On Mon, Nov 9, 2009 at 3:39 PM, jamesmikedup...@googlemail.com
wrote:
[...]
> ./i386-softmmu/qemu -L / /bin/ls
> qemu: could not load PC BIOS 'bios.bin'
>
> Does not work.
Do you know what softmmu means? You should read QEMU
user manual.
[...]
> ./x86_64-softmmu/qemu-system-x86_64 -L / /bin/ls
Hi ,
I have patched the qemu to even build on i386. Now all the targets build,
but I cannot run all targets.
./i386-softmmu/qemu -L / /bin/ls
qemu: could not load PC BIOS 'bios.bin'
Does not work.
./i386-linux-user/qemu-i386 -L / /bin/ls
qemu: Unsupported syscall: 240
qemu: Unsupported syscall:
> 2009/11/7 m9807418 :
>> When I used qemu-system-arm and the -smp option.
>> I key -smp 2.
>> It have a message ""Number of SMP cpus requested (2), exceeds max cpus
>> supported by machine `Versatile' (1) "
>> which files of the qemu source code can i change?
>> And the change can let me emulator
Filip Navara wrote:
The support for multiple keyboard devices is essential for emulating embedded
boards where multiple input devices are present (eg. keypad and rotary encoder)
which are implemented using separate QEMU devices.
Signed-off-by: Filip Navara
What boards would we actually e
Avi Kivity wrote:
On 11/08/2009 12:11 AM, Anthony Liguori wrote:
You don't need root privileges to use a tap device.
You can access a preconfigured tap device but you cannot allocate a
tap device and connect it to a bridge without CAP_NET_ADMIN.
btw, shouldn't we, in the general case, cr
On Sun, Nov 08, 2009 at 06:37:34PM -0700, C.W. Betts wrote:
> In Darwin, the libSystem.B.dylib is a container for a lot of
> libraries, among them is libuuid. However, there isn't, by default, a
> static link libuuid to libSystem. The configure script should just
> check to see if there's
Avi Kivity wrote:
(qemu) info balloon
balloon: actual=1024 MB
balloon: pswapin=0 pages
balloon: pswapout=0 pages
balloon: panon=3928 KB
balloon: pgmajfault=0
balloon: pgminfault=247914
balloon: memfree=987032 KB
ba
On 11/09/2009 03:39 PM, Gerd Hoffmann wrote:
Hi,
Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this
aequivalent to the next option from the scsi point of view), or
scsi-disk would have to support both formats.
A device or device set which is always 64-bit would always us
Hi,
Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this
aequivalent to the next option from the scsi point of view), or
scsi-disk would have to support both formats.
A device or device set which is always 64-bit would always use
QEMUSG64List. A device which is always 32-bi
On 11/09/2009 03:03 PM, Gerd Hoffmann wrote:
On 11/09/09 13:37, Avi Kivity wrote:
On 11/09/2009 11:08 AM, Gerd Hoffmann wrote:
It is because of QEMUSGList which drags in a target_phys_addr_t
dependency.
As Michael notes, devices have physical address sizes independent of the
target platform;
On 11/09/09 13:37, Avi Kivity wrote:
On 11/09/2009 11:08 AM, Gerd Hoffmann wrote:
It is because of QEMUSGList which drags in a target_phys_addr_t
dependency.
As Michael notes, devices have physical address sizes independent of the
target platform; a PCI device that supports 64-bit addresses ca
On 11/09/2009 11:08 AM, Gerd Hoffmann wrote:
You are also moving the compilation to Makefile.hw, which is not
exactly an improvement. Is this needed because of the QEMUIOVector
stuff?
Almost correct ;)
It is because of QEMUSGList which drags in a target_phys_addr_t
dependency.
As Michael
Hello All,
I had a doubt about the COW implementation of QCOW2.
Suppose two clusters point to the same address, then in that case, the
QCOW_OFLAG_COPIED is cleared in the l2 entries for both the clusters.
Now suppose a write is made to any one of the clusters, then how is the
other cluster identif
On 11/07/09 16:22, Blue Swirl wrote:
In general the commits look good, there are many obviously correct cleanups.
However, what happens to the DPRINTFs, it looks like they are removed
in the process?
I guess you are talking about the ones for each emulated command in
scsi-disk.c? There is sc
2009/11/9 yuanzhu86 :
> Hi everyone:
> as I want to analysis the source code of qemu now, and there is a litte
> trouble at this fuction:
> in the file--Translate.c(target-i386)
>
> Line 6113 :
> case 0xea: /* ljmp im */
> {
> unsigned int selector, offset;
> if (COD
51 matches
Mail list logo
