Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
It still exists in userspace. Having the code duplication
(especially when it's not the same code base) is unfortunate.
This remains true.
but it's the wrong argument. Of course there's duplicate functionality,
Ingo Molnar wrote:
we should move all the PICs into KVM proper - and that includes the
i8259A PIC too. Qemu-space drivers are then wired to pins on these PICs,
but nothing in Qemu does vector generation or vector prioritization -
that task is purely up to KVM. There are mixed i8259A+lapic
Ingo Molnar wrote:
there is a remote possibility that some OSs depend on certain devices
being level-triggered: for example if you get an IRQ from a
level-triggered device and _dont_ deassert that signal from the IRQ
handler (intentionally so), then the semantics of current hardware will
Anthony Liguori wrote:
Yeah, I think this is a good point. If we're going to push the APIC
into the kernel, we might as well put the PIT there too. The timing
stuff is an absolute mess in QEMU since it wants to get a fast high
res clock but isn't aware of things like CPU migration.
qemu
Gregory Haskins wrote:
The MMIO registration code has been broken out as a new patch from the
in-kernel APIC work with the following changes per Avi's request:
1) Supports dynamic registration
2) Uses gpa_t addresses
3) Explicit per-cpu mappings
In addition, I have added the concept of
Gregory Haskins wrote:
On Wed, Apr 4, 2007 at 4:32 PM, in message [EMAIL PROTECTED],
Ingo Molnar [EMAIL PROTECTED] wrote:
My current thoughts are that we at least move the IOAPIC into the
kernel as well. [...]
yes. And then do the final 10% move of handling the i8529A
Rusty Russell wrote:
You didn't quote Anthony's point about it's more about there not being
good enough userspace interfaces to do network IO.
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
Ingo Molnar wrote:
we should move all the PICs into KVM proper - and that includes the
i8259A PIC too. Qemu-space drivers are then wired to pins on these
PICs,
but nothing in Qemu does vector generation or vector prioritization -
that task is purely up to KVM. There are mixed i8259A+lapic
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 50
+
drivers/kvm/kvm_main.c | 53
+++---
-
2 files changed, 94 insertions(+), 9 deletions(-)
diff --git
Gregory Haskins wrote:
The MMIO registration code has been broken out as a new patch from the
in-kernel APIC work with the following changes per Avi's request:
1) Supports dynamic registration
2) Uses gpa_t addresses
3) Explicit per-cpu mappings
In addition, I have added the concept of
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think that's
been done, and it would be interesting to
Avi Kivity [EMAIL PROTECTED] writes:
Please test the attached patch, against kvm-17. This is subversion
revision 4546 and git commit c01571ed56754dfea458cc37d553c360082411a1.
Fails.
I notice that a lot of new code is related to pio. Seeing that it locks up when
the VPN starts using the
Ingo Molnar wrote:
so right now the only option for a clean codebase is the KVM in-kernel
code.
I strongly disagree with this. Bad code in userspace is not an excuse
for shoving stuff into the kernel, where maintaining it is much more
expensive, and the cause of a mistake can be system
Is it possible to do a migration (or any other maintenance, like
stopping a guest VM) without qemu-monitor / Alt-Ctrl-2?
For those using Xen, it would be similar to a command line xm which
migrates a guest/domain to a different host - just SSH to your server
(or use it in a script etc.), and
Ingo Molnar wrote:
there's one thing i havent seen mentioned (maybe i missed it): the
ability to save/restore the in-kernel *PIC state. That would be required
for migration/snapshotting/etc.
That is a common requirement for all variants. Actually this is best
implemented (assuming the
For example, lets says you are running several guests, and would like
to
start yet another one for a while - but have no free memory left.
We have another solution for it that will soon be pushed into the
kernel:
It is the balloon driver solution.
Each guest runs a balloon driver, when
* Avi Kivity [EMAIL PROTECTED] wrote:
so right now the only option for a clean codebase is the KVM
in-kernel code.
I strongly disagree with this.
are you disagreeing with my statement that the KVM kernel-side code is
the only clean codebase here? To me this is a clear fact :)
I only
Tomasz Chmielewski wrote:
Look up the qemu -monitor option. This allows you to redirect the
qemu console anywhere you like, including stdio, pipes, tcp sockets,
etc. It's wonderfully flexible.
All right - so I see it belongs more to qemu documentation than KVM's
(+/- KVM extensions
Tomasz Chmielewski wrote:
Is it possible to do a migration (or any other maintenance, like
stopping a guest VM) without qemu-monitor / Alt-Ctrl-2?
For those using Xen, it would be similar to a command line xm which
migrates a guest/domain to a different host - just SSH to your server
(or
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
so right now the only option for a clean codebase is the KVM
in-kernel code.
I strongly disagree with this.
are you disagreeing with my statement that the KVM kernel-side code is
the only clean codebase here? To
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think
1. Make a /tmp/guest socket; then start a guest
qemu (...) -monitor unix:/tmp/quest,server,nowait
2. Show qemu-monitor's help:
echo 'help' | socat - unix-connect:/tmp/quest
You can also try with a tcp device and telnet it.
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
Is it possible to do a migration (or any other maintenance, like
stopping a guest VM) without qemu-monitor / Alt-Ctrl-2?
For those using Xen, it would be similar to a command line xm which
migrates a guest/domain to a different host - just SSH
For example, lets says you are running several guests, and would
like
to
start yet another one for a while - but have no free memory left.
We have another solution for it that will soon be pushed into the
kernel:
It is the balloon driver solution.
Each guest runs a balloon driver, when
I am getting core dumps when running kvm at various times. I am trying
to install WindowsXP as a guest and kvm core dumps at various times
during install, so I have not been able to finish the install.
HP Pavilion dv9297ea Intel Core2Duo 7200, 2GB RAM
VT is enabled in the BIOS and kvm-intel
* Avi Kivity [EMAIL PROTECTED] wrote:
- *pic in kernel: most effort, easiest irq synchronization. Interface
is pic/ioapic pin level, plus a topology description that userspace
uses to tell the hardware how the pins are connected (logically
required, but practically not).
yeah, that
Andrew Henry wrote:
I am getting core dumps when running kvm at various times. I am trying
to install WindowsXP as a guest and kvm core dumps at various times
during install, so I have not been able to finish the install.
HP Pavilion dv9297ea Intel Core2Duo 7200, 2GB RAM
i386? x86_64?
On Thursday 05 April 2007, Dor Laor wrote:
For example, lets says you are running several guests, and would
like
to
start yet another one for a while - but have no free memory left.
We have another solution for it that will soon be pushed into the
kernel:
It is the balloon driver
Arnd Bergmann wrote:
Another driver you might want to look at is the Xen balloon driver:
http://81.161.245.2/lxr/http/source/linux-2.6-xen-
sparse/drivers/xen/balloon/balloon.c
The s390 driver is probably a better example though. One thing the
Xen one got wrong is that its interface requires
Avi Kivity wrote:
Andrew Henry wrote:
I am getting core dumps when running kvm at various times. I am trying
to install WindowsXP as a guest and kvm core dumps at various times
during install, so I have not been able to finish the install.
HP Pavilion dv9297ea Intel Core2Duo 7200, 2GB RAM
Andrew Henry wrote:
Typically, I have now run winXP for 2 hours after it last bombed with 3
mins to go on the installation. WinXP started up fine however, despite
not finishing the install properly. It has not crashed so far :( so I
cannot paste the text of the core dump here. I will post
On Thu, Apr 5, 2007 at 3:46 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
The pit/pic are pio devices, not mmio, so they need their own bus.
Good morning!
Yeah, I knew that but I haven't coded any support for anything but mmio yet.
I explicitly chose the
Dor Laor wrote:
Do you know why Xen guy choose of implementing it in Xen? Why didn't
they rip Qemu implementation?
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among Qemu VMM with less
On Thursday 05 April 2007, Dor Laor wrote:
Currently the only memory-over-commit mechanism is the balloon.
In the future we will add all the wise spectrum of host demand pages,
shared pages, etc.
Ok, just as another hint: you should definitely take a look at
pfault_interrupt() in
Arnd Bergmann wrote:
On Thursday 05 April 2007, Dor Laor wrote:
Currently the only memory-over-commit mechanism is the balloon.
In the future we will add all the wise spectrum of host demand pages,
shared pages, etc.
Ok, just as another hint: you should definitely take a look at
Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level userspace interface isn't possible. I don't think that's
been done, and it
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
any 'cut' of the interface to allow both qemu and KVM generate vectors
is unnecessary (and harmful) complexity. The interface cut should be
at
the 'pin' level, with Qemu raising a signal on a pin and lowering a
signal on a pin, but
On Thursday 05 April 2007, Avi Kivity wrote:
arch/s390/mm/extmem.c has another very interesting concept, though the
hcall interfaces used there are not as flexible as they should be in
kvm. It's basically about mapping host files into the guest real address
space, e.g. for shared memory
On Thursday 05 April 2007, Avi Kivity wrote:
arch/s390/mm/extmem.c has another very interesting concept, though
the
hcall interfaces used there are not as flexible as they should be
in
kvm. It's basically about mapping host files into the guest real
address
space, e.g. for shared memory
Dor Laor wrote:
Dor Laor wrote:
Do you know why Xen guy choose of implementing it in Xen? Why
didn't they rip Qemu implementation?
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among Qemu VMM with less LOC in VMM, it can get
similar performance gain (5.8% in my test).
BTW, at that time, PIT is in VMM
Dor Laor wrote:
So for the sake of the next arguments, what was the fuel running the
decision of moving all the X-PI[c|t] things into the Xen?
PIT is in Xen at very beginning when HVM support is designed due to
performance
reason. Moving PIC to VMM is also for performance reason at that time
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ
linux kernel, KB gets 14% gain. We also did a shared PIC model
which share PIC state among Qemu VMM with less LOC in VMM, it
can get
similar performance gain (5.8% in
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among Qemu VMM with less LOC in VMM, it can get
similar performance gain (5.8% in
Dong, Eddie wrote:
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ
linux kernel, KB gets 14% gain. We also did a shared PIC model
which share PIC state among Qemu VMM with less LOC in VMM, it
can get
Avi Kivity wrote:
lsof -p `pgrep kvm` should list /dev/kvm as an open file. The qemu
window should show QEMU/KVM in the title bar.
kvm is an open file and QEMU/KVM does show in the title bar. I guess
its working, but maybe kvm-16 is still not fully developed/an early
release? Speed is very
Hi All,
The following is another patch that I broke out of the in-kernel-apic patch
that I sent earlier. This focuses purely on the irqdevice abstraction without
introducing the concept of the in-kernel LAPIC. It also provides an
implementation of a userint model, which should support a
On Thu, 2007-04-05 at 13:36 +0200, Ingo Molnar wrote:
prototyping new kernel APIs to implement user-space network drivers, on
a crufty codebase is not something that should be done lightly.
I think you overestimate my radicalism. I was considering readv() and
writev() on the tap device.
49 matches
Mail list logo
