On Thu, Apr 2, 2009 at 07:59, Chris Wright chr...@redhat.com wrote:
* Bert Wesarg (bert.wes...@googlemail.com) wrote:
Unregister a shareable memory region (not currently implemented):
^
madvise(void *addr, size_t len,
Herbert Xu wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
That said, I don't think we're bound today by the fact that we're in
userspace. Rather we're bound by the interfaces we have between the
host kernel and userspace to generate IO. I'd rather fix those
interfaces than put more
Gregory Haskins wrote:
I think there is a slight disconnect here. This is *exactly* what I am
trying to do. You can of course do this many ways, and I am not denying
it could be done a different way than the path I have chosen. One
extreme would be to just slam a virtio-net specific chunk
Brian Jackson wrote:
I don't think the kvm-guest-drivers are still well maintained (they haven't
been touched in 5 months). If you are using kernel 2.6.29, it already has
virtio drivers and you don't need the kvm-guest-drivers tree at all.
That is correct. The effort to maintain a network
Anthony Liguori wrote:
I disagree with this. While virtio is excellent at exporting guest
memory, it isn't so good at importing another guest's memory.
First we need to separate static memory sharing and dynamic memory
sharing. Static memory sharing has to be configured on start up. I
Cam Macdonell wrote:
I think there is value for static memory sharing. It can be used for
fast, simple synchronization and communication between guests (and the
host) that use need to share data that needs to be updated frequently
(such as a simple cache or notification system). It may not
Chris Wright wrote:
I can't find a definition for MADV_UNSHAREABLE!
It's not there ;-)
You were not able to share it with us?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line
Anthony Liguori wrote:
I'm often afraid of what sort of bugs we'd uncover in kvm if we passed
the fds around via SCM_RIGHTS and started poking around :-/
kvm checks the mm doesn't change underneath.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to
Avi Kivity a...@redhat.com wrote:
virtio is already non-kvm-specific (lguest uses it) and non-pci-specific
(s390 uses it).
I think Greg's work shows that putting the backend in the kernel
can dramatically reduce the cost of a single guest-host transaction.
I'm sure the same thing would work
On Thu, Apr 02, 2009 at 09:46:49AM +0300, Avi Kivity wrote:
I don't understand this. If we had good interfaces, all that userspace
would do is translate guest physical addresses to host physical
addresses, and translate the guest-host protocol to host API calls. I
don't see anything
Dong, Eddie wrote:
Thx, eddie
This code just got rewritten by Gleb. Please check again after I push.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On Thu, Apr 02, 2009 at 12:02:09PM +0300, Avi Kivity wrote:
There is no choice. Exiting from the guest to the kernel to userspace
is prohibitively expensive, you can't do that on every packet.
I was referring to the bit between the kernel and userspace.
In any case, I just looked at the
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 12:02:09PM +0300, Avi Kivity wrote:
There is no choice. Exiting from the guest to the kernel to userspace
is prohibitively expensive, you can't do that on every packet.
I was referring to the bit between the kernel and userspace.
In any
On Thu, Apr 02, 2009 at 12:27:17PM +0300, Avi Kivity wrote:
If tap told us when the packets were actually transmitted, life would be
wonderful:
And why do we need this? Because we are in user space!
I'll continue to wait for your patch and numbers :)
Cheers,
--
Visit Openswan at
On Thu, Apr 02, 2009 at 05:29:36PM +0800, Herbert Xu wrote:
On Thu, Apr 02, 2009 at 12:27:17PM +0300, Avi Kivity wrote:
If tap told us when the packets were actually transmitted, life would be
wonderful:
And why do we need this? Because we are in user space!
I'll continue to wait
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 12:27:17PM +0300, Avi Kivity wrote:
If tap told us when the packets were actually transmitted, life would be
wonderful:
And why do we need this? Because we are in user space!
Why does a kernel solution not need to know when a packet is
On Wed, Apr 01, 2009 at 09:36:31PM -0500, Anthony Liguori wrote:
on this behavior to unregister memory regions, you could potentially have
badness happen in the kernel if ksm attempted to access an invalid memory
region.
How could you possibly come to this conclusion? If badness could ever
On Thu, Apr 02, 2009 at 12:38:46PM +0300, Avi Kivity wrote:
Why does a kernel solution not need to know when a packet is transmitted?
Because you can install your own destructor?
I don't know what Greg did, but netback did that nasty page destructor
hack which Jeremy is trying to undo :)
Herbert Xu wrote:
Avi Kivity a...@redhat.com wrote:
virtio is already non-kvm-specific (lguest uses it) and non-pci-specific
(s390 uses it).
I think Greg's work shows that putting the backend in the kernel
can dramatically reduce the cost of a single guest-host transaction.
I'm sure
Zhang, Yang wrote:
The data from dma will include instructions. In order to exeuting the right
instruction, we should to flush the i-cache to ensure those data can be see
by cpu.
diff --git a/qemu/cache-utils.h b/qemu/cache-utils.h
index b45fde4..5e11d12 100644
--- a/qemu/cache-utils.h
+++
Hi Jesse!
Jesse Ahrens schrieb:
Via engineers have contacted me and confirmed that this is a problem in
the processor.
I'd like to clarify. Stepping 2 Nano processors do not support VMX.
This should have been disabled by the BIOS. Support for VMX was not
finished until stepping 3. If you
On Thu, Apr 02, 2009 at 12:43:54PM +0300, Avi Kivity wrote:
So we're back to the problem is with the kernel-user interface, not
userspace being cursed into slowness.
Well until you have a patch + numbers that's only an allegation :)
--
Visit Openswan at http://www.openswan.org/
Email:
Sheng Yang wrote:
1. It's related to a Linux kernel bug which fixed by Ingo on
07a66d7c53a538e1a9759954a82bb6c07365eff9. The original code exists for quite a
long time, and it would convert a PDE for large page into a normal PDE. But it
fail to fit normal PDE well. With the code before Ingo's
On Thu, Apr 02, 2009 at 11:59:35AM +0300, Avi Kivity wrote:
Dong, Eddie wrote:
Thx, eddie
This code just got rewritten by Gleb. Please check again after I push.
My patch adds the check.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
On Thu, Apr 02, 2009 at 12:03:32PM +0300, Avi Kivity wrote:
Like Anthony said, the problem is with the kernel-user interfaces. We
won't have a good user space virtio implementation until that is fixed.
If it's just the interface that's bad, then it should be possible
to do a
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 09:46:49AM +0300, Avi Kivity wrote:
I don't understand this. If we had good interfaces, all that userspace
would do is translate guest physical addresses to host physical
addresses, and translate the guest-host protocol to host API calls. I
Zhang, Yang wrote:
when using make in kernel, it can not find msidef.h. This patch
fix this.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
Zhang, Yang wrote:
fix compilation error in IA64
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
1. How does Qemu process start running in Guest?
2. How does a guest's I/O request get trapped into the user mode qemu process?
Thx,
Venkat
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Avi Kivity wrote:
Gregory Haskins wrote:
I think there is a slight disconnect here. This is *exactly* what I am
trying to do. You can of course do this many ways, and I am not denying
it could be done a different way than the path I have chosen. One
extreme would be to just slam a
Avi Kivity wrote:
Herbert Xu wrote:
Avi Kivity a...@redhat.com wrote:
virtio is already non-kvm-specific (lguest uses it) and
non-pci-specific (s390 uses it).
I think Greg's work shows that putting the backend in the kernel
can dramatically reduce the cost of a single guest-host
Avi Kivity wrote:
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 12:27:17PM +0300, Avi Kivity wrote:
If tap told us when the packets were actually transmitted, life
would be wonderful:
And why do we need this? Because we are in user space!
Why does a kernel solution not need to
Anthony Liguori wrote:
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
The ioctl() interface is quite bad for what you're doing. You're
telling the kernel extra information about a VA range in
userspace. That's what madvise is for. You're tweaking simple
Hello,
commit 9c46f6d42f1b5627c49a5906cb5b315ad8716ff0
Author: Alex Williamson alex.william...@hp.com
Date: Wed Feb 4 16:36:34 2009 -0800
virtio_net: Allow setting the MAC address of the NIC
Introduced an unconditional config-set to the MAC address field of
the device config.
+ } else
Stephen Hemminger wrote:
On Tue, 31 Mar 2009 14:43:34 -0400
Gregory Haskins ghask...@novell.com wrote:
+struct vbus_enet_priv {
+spinlock_t lock;
+struct net_device *dev;
+struct vbus_device_proxy *vdev;
+struct napi_struct napi;
+
Gregory Haskins wrote:
virtio is already non-kvm-specific (lguest uses it) and
non-pci-specific (s390 uses it).
Ok, then to be more specific, I need it to be more generic than it
already is. For instance, I need it to be able to integrate with
shm_signals.
Why?
If you have a
Gregory Haskins wrote:
There is no choice. Exiting from the guest to the kernel to userspace
is prohibitively expensive, you can't do that on every packet.
Now you are making my point ;) This is part of the cost of your
signaling path, and it directly adds to your latency time.
Gregory Haskins wrote:
Why does a kernel solution not need to know when a packet is transmitted?
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there are problems with
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there are problems with the reliability of proper
callback (i.e.
Avi Kivity wrote:
Gregory Haskins wrote:
virtio is already non-kvm-specific (lguest uses it) and
non-pci-specific (s390 uses it).
Ok, then to be more specific, I need it to be more generic than it
already is. For instance, I need it to be able to integrate with
shm_signals.
Avi Kivity wrote:
Gregory Haskins wrote:
Why does a kernel solution not need to know when a packet is
transmitted?
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it
Gregory Haskins wrote:
Avi Kivity wrote:
Gregory Haskins wrote:
virtio is already non-kvm-specific (lguest uses it) and
non-pci-specific (s390 uses it).
Ok, then to be more specific, I need it to be more generic than it
already is. For instance, I need it to be able
Gregory Haskins wrote:
It's more of a schedule and forget which I think brings you the
win. The host disables notifications and schedules the actual tx work
(rx from the host's perspective). So now the guest and host continue
producing and consuming packets in parallel. So long as the
Rusty Russell wrote:
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there are problems with the reliability of
Gregory Haskins wrote:
Rusty Russell wrote:
there will *never* be another packet in the queue
at this point, since it wasn't running.
Yep, and I'll be the first to admit that my design only looks forward.
To clarify, I am referring to the internal design of the venet-tap
The length of pushed on to the stack return address depends on operand
size not address size.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index ca91749..d7c9f6f 100644
--- a/arch/x86/kvm/x86_emulate.c
+++
Avi Kivity wrote:
My 'prohibitively expensive' is true only if you exit every packet.
Understood, but yet you need to do this if you want something like iSCSI
READ transactions to have as low-latency as possible.
-Greg
signature.asc
Description: OpenPGP digital signature
Avi Kivity wrote:
Gregory Haskins wrote:
It's more of a schedule and forget which I think brings you the
win. The host disables notifications and schedules the actual tx work
(rx from the host's perspective). So now the guest and host continue
producing and consuming packets in
Gregory Haskins wrote:
Rusty Russell wrote:
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there are
Gregory Haskins wrote:
Avi Kivity wrote:
My 'prohibitively expensive' is true only if you exit every packet.
Understood, but yet you need to do this if you want something like iSCSI
READ transactions to have as low-latency as possible.
Dunno, two microseconds is too much? The
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c
index f6d5326..336ba1c 100644
--- a/user/test/x86/realmode.c
+++ b/user/test/x86/realmode.c
@@ -361,14 +361,94 @@ void test_io(void)
void test_call(void)
{
struct regs inregs = {
Avi Kivity wrote:
Gregory Haskins wrote:
Rusty Russell wrote:
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to
support,
but as I understand
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
Using an interface like madvise() would force the issue to be dealt with
properly from the start :-)
Yeah, I'm not at all opposed to it.
This updates to madvise for register and sysfs for control.
madvise issues:
Gregory Haskins wrote:
Avi Kivity wrote:
Gregory Haskins wrote:
Avi Kivity wrote:
My 'prohibitively expensive' is true only if you exit every packet.
Understood, but yet you need to do this if you want something like iSCSI
READ transactions to have as
Gregory Haskins wrote:
If you have a request-response workload with the wire idle and latency
critical, then there's no problem having an exit per packet because
(a) there aren't that many packets and (b) the guest isn't doing any
batching, so guest overhead will swamp the hypervisor overhead.
On Thu, 2009-04-02 at 16:27 +0300, Avi Kivity wrote:
virtio is a stable ABI.
However, theres still the possibility we can make this work in an ABI
friendly way with cap-bits, or other such features. For instance, the
virtio-net driver could register both with pci and vbus-proxy and
On Wed, Apr 01, 2009 at 10:31:14PM -0700, Chris Wright wrote:
- register only ATM, can add MADV_UNSHAREABLE to allow an app to proactively
unregister, but need a cleanup when -mm goes away via exit/exec
The unregister cleanup must happen at the vma level (with unregister
when vma goes
Avi Kivity wrote:
The alternative is to get a notification from the stack that the
packet is done processing. Either an skb destructor in the kernel, or
my new API that everyone is not rushing out to implement.
btw, my new api is
io_submit(..., nr, ...): submit nr packets
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 04:07:09PM +0300, Avi Kivity wrote:
I think Rusty did mean a UP guest, and without schedule-and-forget.
Going off on a tangent here, I don't really think it should matter
whether we're UP or SMP. The ideal state is where we have the
same
On Thu, Apr 02, 2009 at 10:43:19PM +1030, Rusty Russell wrote:
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there
* Andrea Arcangeli (aarca...@redhat.com) wrote:
On Wed, Apr 01, 2009 at 10:31:14PM -0700, Chris Wright wrote:
- register only ATM, can add MADV_UNSHAREABLE to allow an app to
proactively
unregister, but need a cleanup when -mm goes away via exit/exec
The unregister cleanup must
Avi Kivity wrote:
Patrick Mullaney wrote:
On Thu, 2009-04-02 at 16:27 +0300, Avi Kivity wrote:
virtio is a stable ABI.
However, theres still the possibility we can make this work in an ABI
friendly way with cap-bits, or other such features. For instance, the
virtio-net driver
Gregory Haskins wrote:
vbus (if I understand it right) is a whole package of things:
- a way to enumerate, discover, and manage devices
Yes
That part duplicates PCI
Yes, but the important thing to point out is it doesn't *replace* PCI.
It simply an alternative.
Does it
Andi Kleen wrote:
On Wed, Apr 01, 2009 at 07:21:55PM -0400, Masami Hiramatsu wrote:
Andi Kleen wrote:
On Wed, Apr 01, 2009 at 04:51:00PM -0400, Masami Hiramatsu wrote:
Andi Kleen wrote:
Masami Hiramatsu mhira...@redhat.com writes:
I agreed. Fortunately, Jim Keniston and I wrote an x86
tging...@free.fr wrote:
What about smp?
fc will broadcast to the coherence domain the cache invalidation. So it is
SMP-ready for usual machines.
Interesting.
I'm surprised the guest doesn't do this by itself?
It doesn't had to do it. The PCI transaction will
* Izik Eidus (iei...@redhat.com) wrote:
Is this what we want?
How about baby steps...
admit that ioctl to control plane is better done via sysfs?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 06:00:17PM +0300, Avi Kivity wrote:
Good point - if we rely on having excess cores in the host, large guest
scalability will drop.
Going back to TX mitigation, I wonder if we could avoid it altogether
by having a wakeup mechanism that does
Avi Kivity wrote:
It doesn't had to do it. The PCI transaction will automatically
invalidate
caches - but qemu doesn't emulate this (and doesn't need to do on x86).
So any DMA on ia64 will flush the instruction caches?!
Or maybe, the host kernel will do it after the transaction
Chris Wright wrote:
* Izik Eidus (iei...@redhat.com) wrote:
Is this what we want?
How about baby steps...
admit that ioctl to control plane is better done via sysfs?
Yes
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Thu, 2009-04-02 at 13:33 +0200, Christian Borntraeger wrote:
I read this as the mac config field is optional (similar to all the optional
fields we added in virtio_blk later).
I see two options:
1. Change our sample userspace to always allocate the config (like lguest and
qemu)
2.
On Tue, 2009-03-31 at 14:42 -0400, Gregory Haskins wrote:
[...]
+Create a device instance
+
+
+Devices are instantiated by again utilizing the /config/vbus configfs area.
+At first you may suspect that devices are created as subordinate objects of a
+bus/container
Anthony Liguori wrote:
I don't think we even need that to end this debate. I'm convinced we
have a bug somewhere. Even disabling TX mitigation, I see a ping
latency of around 300ns whereas it's only 50ns on the host. This
defies logic so I'm now looking to isolate why that is.
I'm down to
Herbert Xu wrote:
On Thu, Apr 02, 2009 at 06:57:38PM +0300, Avi Kivity wrote:
What if the guest sends N packets, then does some expensive computation
(say the guest scheduler switches from the benchmark process to
evolution). So now we have the marker set at packet N, but the host
will
It is my understanding that you need vt-d/iommu support. I didn't think any
existing amd chipsets had iommu support. You may want to look into that.
--Brian Jackson
On Thursday 02 April 2009 07:00:07 Hauke Hoffmann wrote:
Hi,
qemu-system-x86_64 runs well and i can boot and run the guest
On Thu, Apr 02, 2009 at 07:54:21PM +0300, Avi Kivity wrote:
3ms latency for ping?
(ping will always be scheduled immediately when the reply arrives if I
understand cfs, so guest load won't delay it)
That only happens if the guest immediately does some CPU-intensive
computation 3ms and
On Fri, Apr 03, 2009 at 01:06:10AM +0800, Herbert Xu wrote:
That only happens if the guest immediately does some CPU-intensive
computation 3ms and assuming its timeslice lasts that long.
In any case, the same thing will happen right now if the host or
some other guest on the same CPU hogs
Hi,
Here are the patches of kprobe-based event tracer for x86, version 4.
This version supports only x86(-32/-64) (If someone is interested in
porting this to other architectures, he just needs to port
kprobes/kretprobes and ptrace enhancement[PATCH 2/6]).
I added x86 insn decoder on this
Am Thursday 02 April 2009 18:06:25 schrieb Alex Williamson:
On Thu, 2009-04-02 at 13:33 +0200, Christian Borntraeger wrote:
I read this as the mac config field is optional (similar to all the optional
fields we added in virtio_blk later).
[...]
Sorry for the breakage. My interpretation of
Add following APIs for accessing registers and stack entries from pt_regs.
- query_register_offset(const char *name)
Query the offset of name register.
- query_register_name(unsigned offset)
Query the name of register by its offset.
- get_register(struct pt_regs *regs, unsigned offset)
Use regs-sp instead of regs for getting the top of stack in kernel mode.
(on x86-64, regs-sp always points the top of stack)
Signed-off-by: Masami Hiramatsu mhira...@redhat.com
Cc: Harvey Harrison harvey.harri...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc:
Add x86 instruction decoder to arch-specific libraries. This decoder
can decode all x86 instructions into prefix, opcode, modrm, sib,
displacement and immediates. This can also show the length of
instructions.
Signed-off-by: Jim Keniston jkeni...@us.ibm.com
Signed-off-by: Masami Hiramatsu
Ensure safeness of inserting kprobes by checking whether the specified
address is at the first byte of a instruction. This is done by decoding
probed function from its head to the probe point.
Signed-off-by: Masami Hiramatsu mhira...@redhat.com
Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com
Cc:
Add kprobes based event tracer on ftrace.
This tracer is similar to the events tracer which is based on Tracepoint
infrastructure. Instead of Tracepoint, this tracer is based on kprobes(kprobe
and kretprobe). It probes anywhere where kprobes can probe(this means, all
functions body except for
Support following probe arguments and add fetch functions on kprobe-tracer.
%REG : Fetch register REG
sN: Fetch Nth entry of stack (N = 0)
@ADDR : Fetch memory at ADDR (ADDR should be in kernel)
@SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
aN: Fetch
Avi Kivity wrote:
Gregory Haskins wrote:
vbus (if I understand it right) is a whole package of things:
- a way to enumerate, discover, and manage devices
Yes
That part duplicates PCI
Yes, but the important thing to point out is it doesn't *replace*
PCI. It simply an
Hi Ben
Ben Hutchings wrote:
On Tue, 2009-03-31 at 14:42 -0400, Gregory Haskins wrote:
[...]
+Create a device instance
+
+
+Devices are instantiated by again utilizing the /config/vbus configfs area.
+At first you may suspect that devices are created as
Avi Kivity wrote:
Anthony Liguori wrote:
I don't think we even need that to end this debate. I'm convinced
we have a bug somewhere. Even disabling TX mitigation, I see a ping
latency of around 300ns whereas it's only 50ns on the host. This
defies logic so I'm now looking to isolate why
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
.gitignore |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index fcdc357..22a8200 100644
--- a/.gitignore
+++ b/.gitignore
@@ -53,10 +53,14 @@ kernel/x86/coalesced_mmio.[ch]
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu/hw/extboot.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu/hw/extboot.c b/qemu/hw/extboot.c
index 32e6226..13ffafa 100644
--- a/qemu/hw/extboot.c
+++ b/qemu/hw/extboot.c
@@ -77,8 +77,8 @@ static void
Hi,
On Tue, 31 Mar 2009, Izik Eidus wrote:
KSM is a linux driver that allows dynamicly sharing identical memory
pages between one or more processes.
Unlike tradtional page sharing that is made at the allocation of the
memory, ksm do it dynamicly after the memory was created.
Memory is
* Jesper Juhl (j...@chaosbits.net) wrote:
Do you rely only on the checksum or do you actually compare pages to check
they are 100% identical before sharing?
Checksum has absolutely nothing to do w/ finding if two pages match.
It's only used as a heuristic to suggest whether a single page has
Jesper Juhl wrote:
Hi,
On Tue, 31 Mar 2009, Izik Eidus wrote:
KSM is a linux driver that allows dynamicly sharing identical memory
pages between one or more processes.
Unlike tradtional page sharing that is made at the allocation of the
memory, ksm do it dynamicly after the memory was
On Thu, 2 Apr 2009, Chris Wright wrote:
* Jesper Juhl (j...@chaosbits.net) wrote:
Do you rely only on the checksum or do you actually compare pages to check
they are 100% identical before sharing?
Checksum has absolutely nothing to do w/ finding if two pages match.
It's only used as a
* Gleb Natapov g...@redhat.com [2009-04-01 09:54]:
On Wed, Apr 01, 2009 at 05:49:08PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
Commit 3d28613c225ba94062950dacbb2304b2d2024abc break linux boot.
It hangs after printing:
SMP alternatives: switching to UP code
Does dropping bit
Hello,
I am a new user to KVM and was wondering if there was any way to
limit a VE from using up all the resources of the processor.
Right now I have a Quad core 2.5Ghz, I have a KVM VE (running windows
server 2003) and assigned 4 CPUs to it. If I max out the load for that
VE, the entire host
There's CPU cgroups. It doesn't have exactly the ability you are after, but it
is able to limit process(es) CPU usage. Maxing out CPU usage won't crash your
server. The kernel will arbitrate sharing the CPU evenly among processes/VMs.
--Brian Jackson
On Thursday 02 April 2009 16:41:10
I haven't ever really used cgroups. I always figured a fair host scheduler is
good enough to handle spreading load. So I don't know if it will fit exactly
what you need. I don't think so. I also don't know of any other options. I
will say, If I gave 4 VMs a single cpu each on a 4 core host, I
On Thu, Apr 02, 2009 at 01:24:47PM -0400, Masami Hiramatsu wrote:
Add following APIs for accessing registers and stack entries from pt_regs.
- query_register_offset(const char *name)
Query the offset of name register.
- query_register_name(unsigned offset)
Query the name of register
Looks like cut-n-paste error. We should be fetching values from
nic_params, not image params.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
diffstat output:
kvm_vm.py |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
The wiki documents[1] object addressing quite well, but we should
include it in the example config file as well.
1.
http://www.linux-kvm.org/page/KVM-Autotest/Parameters#Addressing_objects_.28VMs.2C_images.2C_NICs_etc.29
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp.,
1 - 100 of 112 matches
Mail list logo
