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.
Qem
On Thu, 2007-04-05 at 10:17 +0300, Avi Kivity wrote:
> 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
I found a latent bug with my irqdevice.patch during internal review. Since we
don't yet use the NMI filtering feature it was not possible for this to cause
any real problem, but it should be fixed nonetheless. Here is a patch to apply
after the original. I will wait for feedback before postin
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 sy
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 v
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 wit
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 perfor
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 p
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 my te
Hi Avi,
I have addressed your comments and re-attached the fixed up patch. Most of
the things you suggested I implemented, but a few I didnt so I will comment
inline...
>>> On Thu, Apr 5, 2007 at 3:07 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Hask
Avi Kivity wrote:
> 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 differen
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:
>> 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
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
>
>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 sha
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 me
>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
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 p
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
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
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 arch/s390/m
Dong, Eddie 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 sha
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 l
Gregory Haskins wrote:
>> The pit/pic are pio devices, not mmio, so they need their own bus.
>>
>
> Yeah, I knew that but I haven't coded any support for anything but mmio
> yet. I explicitly chose the "kvm_io_XX" name instead of kvm_mmio_XXX in
> hopes that I can use the same structure f
>>> 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
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 po
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,
>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 inter
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 requ
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:
>
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_
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 modul
>> >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 ba
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 h
>>
>> 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.
* 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 thi
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.
Ingo
-
Take Surveys. Earn Cash. Influence
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> [...] But the difference in cruftiness between kvm and qemu code
> should not enter into the discussion of where to do things.
i agree that it doesnt enter the discussion for the *PIC question, but
it very much enters the discussion for the question th
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 serve
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
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 exte
* 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
> >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 dr
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 t
* 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
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:
> 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 cra
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 usin
* 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
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 concep
>> 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
>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+la
-
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
http://www.techsay.com
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-le
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% mov
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 concep
56 matches
Mail list logo
