[ANNOUNCE] kvm-46 release

[ANNOUNCE] kvm-46 release

[Avi Kivity]

We've now switched to allocating guest memory in userspace rather than
in the kernel.  This is important if you have a mainframe, but also if
you want to share memory between guests and implement nice features like
swapping.

Changes since kvm-45:
- fix host oops on bad guest ioapic accesses
- handle NMIs before enabling host interrupts
- add general guest memory accessors (Izik Eidus)
- allow user control over shadow cache size (Izik Eidus)
- auto tune shadow cache size with guest memory (Izik Eidus)
- allocate guest memory in userspace instead of in kernel (Izik Eidus)
- code style fixes (Mike Day, Anthony Liguori)
- lapic cleanups (Rusty Russell)
- fix acpi interrupt reporting for FreeBSD
- fix color problems on certain displays
- Red Hat 7.1 support
- vmmouse support (Dan Kenigsberg)
- fix sdl window caption when keyboard is captured (Dan Kenigsberg)
- improve libkvm configure script (Jerone Young)
- improve bios compilation support on x86_64 hosts (Laurent Vivier)
- fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng
Yang)


Notes:
    If you use the modules bundled with kvm-46, you can use any version
of Linux from 2.6.9 upwards.
    If you use the modules bundled with Linux 2.6.20, you need to use
kvm-12.
    If you use the modules bundled with Linux 2.6.21, you need to use
kvm-17.
    Modules from Linux 2.6.22 and up will work with any kvm version from
kvm-22.  Some features may only be available in newer releases.
    For best performance, use Linux 2.6.23-rc2 or later as the host.

http://kvm.qumranet.com



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Jun Koi]

Hi,

On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.  This is important if you have a mainframe, but also if
> you want to share memory between guests and implement nice features like
> swapping.

This is interesting! But how can we do that now? (share memory between guests)

Thanks,
Jun

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Jun Koi wrote:
> Hi,
>
> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>   
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.  This is important if you have a mainframe, but also if
>> you want to share memory between guests and implement nice features like
>> swapping.
>>     
>
> This is interesting! But how can we do that now? (share memory between guests)
>
>   

It's not exposed by qemu, but you can now mmap() some file (or use SysV
shared memory) and use that as guest memory.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Jun Koi]

On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> Jun Koi wrote:
> > Hi,
> >
> > On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >
> >> We've now switched to allocating guest memory in userspace rather than
> >> in the kernel.  This is important if you have a mainframe, but also if
> >> you want to share memory between guests and implement nice features like
> >> swapping.
> >>
> >
> > This is interesting! But how can we do that now? (share memory between guests)
> >
> >
>
> It's not exposed by qemu, but you can now mmap() some file (or use SysV
> shared memory) and use that as guest memory.
>

OK, lets say we have 2 guest VMs share a memory, like mmap() a tmpfs
file (which is actually in memory). Now one writes to the memory
(shared file). Can we guarantee that the memory immediately updated,
so other will see the change immediately? Or the data might be cached
for a while, befere being flushed to the shared memory?

Thanks,
Jun

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Jun Koi wrote:
> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>   
>> Jun Koi wrote:
>>     
>>> Hi,
>>>
>>> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>>       
>>>> We've now switched to allocating guest memory in userspace rather than
>>>> in the kernel.  This is important if you have a mainframe, but also if
>>>> you want to share memory between guests and implement nice features like
>>>> swapping.
>>>>
>>>>         
>>> This is interesting! But how can we do that now? (share memory between guests)
>>>
>>>
>>>       
>> It's not exposed by qemu, but you can now mmap() some file (or use SysV
>> shared memory) and use that as guest memory.
>>
>>     
>
> OK, lets say we have 2 guest VMs share a memory, like mmap() a tmpfs
> file (which is actually in memory). Now one writes to the memory
> (shared file). Can we guarantee that the memory immediately updated,
> so other will see the change immediately? Or the data might be cached
> for a while, befere being flushed to the shared memory?
>   

Changes are visible immediately.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Jun Koi]

On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> Jun Koi wrote:
> > On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >
> >> Jun Koi wrote:
> >>
> >>> Hi,
> >>>
> >>> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >>>
> >>>
> >>>> We've now switched to allocating guest memory in userspace rather than
> >>>> in the kernel.  This is important if you have a mainframe, but also if
> >>>> you want to share memory between guests and implement nice features like
> >>>> swapping.
> >>>>
> >>>>
> >>> This is interesting! But how can we do that now? (share memory between guests)
> >>>
> >>>
> >>>
> >> It's not exposed by qemu, but you can now mmap() some file (or use SysV
> >> shared memory) and use that as guest memory.
> >>
> >>
> >
> > OK, lets say we have 2 guest VMs share a memory, like mmap() a tmpfs
> > file (which is actually in memory). Now one writes to the memory
> > (shared file). Can we guarantee that the memory immediately updated,
> > so other will see the change immediately? Or the data might be cached
> > for a while, befere being flushed to the shared memory?
> >
>
> Changes are visible immediately.
>

OK, that is about sharing memory file. How about a shared file in
which a file is a real physical file on the host?

As far as I remember, there is a caution about sharing a file using
mmap() between 2 processes, that is: if the first process modifies the
shared file, it might take a while for the changes to be flushed from
cache to the file. That means the other process doesnt see the change
immediately.

I guess this problem affects us in this case, when we use a real
(physical) file to share between 2 VMs, correct?

Thanks,
Jun

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Anthony Liguori]

Jun Koi wrote:
> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>   
>> Jun Koi wrote:
>>     
>>> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>>       
>>>> Jun Koi wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> We've now switched to allocating guest memory in userspace rather than
>>>>>> in the kernel.  This is important if you have a mainframe, but also if
>>>>>> you want to share memory between guests and implement nice features like
>>>>>> swapping.
>>>>>>
>>>>>>
>>>>>>             
>>>>> This is interesting! But how can we do that now? (share memory between guests)
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> It's not exposed by qemu, but you can now mmap() some file (or use SysV
>>>> shared memory) and use that as guest memory.
>>>>
>>>>
>>>>         
>>> OK, lets say we have 2 guest VMs share a memory, like mmap() a tmpfs
>>> file (which is actually in memory). Now one writes to the memory
>>> (shared file). Can we guarantee that the memory immediately updated,
>>> so other will see the change immediately? Or the data might be cached
>>> for a while, befere being flushed to the shared memory?
>>>
>>>       
>> Changes are visible immediately.
>>
>>     
>
> OK, that is about sharing memory file. How about a shared file in
> which a file is a real physical file on the host?
>
> As far as I remember, there is a caution about sharing a file using
> mmap() between 2 processes, that is: if the first process modifies the
> shared file, it might take a while for the changes to be flushed from
> cache to the file. That means the other process doesnt see the change
> immediately.
>   

Changes to a mmap() file may not be flushed to the disk until an msync 
or munmap but if you've got it opened with MAP_SHARED, then everyone 
mapping will have access to the same physical memory IIUC.  You still 
need to use barriers to take into account SMP.  There may be some weird 
interactions if the area isn't mlocked but I'm not totally sure on that.

Regards,

Anthony Liguori

> I guess this problem affects us in this case, when we use a real
> (physical) file to share between 2 VMs, correct?
>
> Thanks,
> Jun
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.  This is important if you have a mainframe, but also if
> you want to share memory between guests and implement nice features like
> swapping.
> 
> Changes since kvm-45:
> - fix host oops on bad guest ioapic accesses
> - handle NMIs before enabling host interrupts
> - add general guest memory accessors (Izik Eidus)
> - allow user control over shadow cache size (Izik Eidus)
> - auto tune shadow cache size with guest memory (Izik Eidus)
> - allocate guest memory in userspace instead of in kernel (Izik Eidus)
> - code style fixes (Mike Day, Anthony Liguori)
> - lapic cleanups (Rusty Russell)
> - fix acpi interrupt reporting for FreeBSD
> - fix color problems on certain displays
> - Red Hat 7.1 support
> - vmmouse support (Dan Kenigsberg)
> - fix sdl window caption when keyboard is captured (Dan Kenigsberg)
> - improve libkvm configure script (Jerone Young)
> - improve bios compilation support on x86_64 hosts (Laurent Vivier)
> - fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng
> Yang)

when i try to compile it on centos i've got this error (which is not
happend in kvm-45) :
----------------------------------
iasl -tc -p acpi-dsdt.hex acpi-dsdt.dsl
make[1]: iasl: Command not found
----------------------------------
where this iasl comes from? and where can i found it? i can't found in
any package even in external repos.

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Farkas Levente wrote:
> Avi Kivity wrote:
>   
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.  This is important if you have a mainframe, but also if
>> you want to share memory between guests and implement nice features like
>> swapping.
>>
>> Changes since kvm-45:
>> - fix host oops on bad guest ioapic accesses
>> - handle NMIs before enabling host interrupts
>> - add general guest memory accessors (Izik Eidus)
>> - allow user control over shadow cache size (Izik Eidus)
>> - auto tune shadow cache size with guest memory (Izik Eidus)
>> - allocate guest memory in userspace instead of in kernel (Izik Eidus)
>> - code style fixes (Mike Day, Anthony Liguori)
>> - lapic cleanups (Rusty Russell)
>> - fix acpi interrupt reporting for FreeBSD
>> - fix color problems on certain displays
>> - Red Hat 7.1 support
>> - vmmouse support (Dan Kenigsberg)
>> - fix sdl window caption when keyboard is captured (Dan Kenigsberg)
>> - improve libkvm configure script (Jerone Young)
>> - improve bios compilation support on x86_64 hosts (Laurent Vivier)
>> - fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng
>> Yang)
>>     
>
> when i try to compile it on centos i've got this error (which is not
> happend in kvm-45) :
> ----------------------------------
> iasl -tc -p acpi-dsdt.hex acpi-dsdt.dsl
> make[1]: iasl: Command not found
> ----------------------------------
> where this iasl comes from? and where can i found it? i can't found in
> any package even in external repos.
>
>   

How did you get this?  Normal 'make' doesn't try to compile the bios.

You can download the iasl compiler from 
http://www.intel.com/technology/iapc/acpi/downloads.htm.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>  
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.  This is important if you have a mainframe, but also if
>>> you want to share memory between guests and implement nice features like
>>> swapping.
>>>
>>> Changes since kvm-45:
>>> - fix host oops on bad guest ioapic accesses
>>> - handle NMIs before enabling host interrupts
>>> - add general guest memory accessors (Izik Eidus)
>>> - allow user control over shadow cache size (Izik Eidus)
>>> - auto tune shadow cache size with guest memory (Izik Eidus)
>>> - allocate guest memory in userspace instead of in kernel (Izik Eidus)
>>> - code style fixes (Mike Day, Anthony Liguori)
>>> - lapic cleanups (Rusty Russell)
>>> - fix acpi interrupt reporting for FreeBSD
>>> - fix color problems on certain displays
>>> - Red Hat 7.1 support
>>> - vmmouse support (Dan Kenigsberg)
>>> - fix sdl window caption when keyboard is captured (Dan Kenigsberg)
>>> - improve libkvm configure script (Jerone Young)
>>> - improve bios compilation support on x86_64 hosts (Laurent Vivier)
>>> - fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng
>>> Yang)
>>>     
>>
>> when i try to compile it on centos i've got this error (which is not
>> happend in kvm-45) :
>> ----------------------------------
>> iasl -tc -p acpi-dsdt.hex acpi-dsdt.dsl
>> make[1]: iasl: Command not found
>> ----------------------------------
>> where this iasl comes from? and where can i found it? i can't found in
>> any package even in external repos.
>>
>>   
> 
> How did you get this?  Normal 'make' doesn't try to compile the bios.

yes, but my spec based on fedora spec which use Jeremy Katz's patch to
bios boot menu, that's way i need it.

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Farkas Levente wrote:
> Avi Kivity wrote:
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.  This is important if you have a mainframe, but also if
>> you want to share memory between guests and implement nice features like
>> swapping.
>>
>> Changes since kvm-45:
>> - fix host oops on bad guest ioapic accesses
>> - handle NMIs before enabling host interrupts
>> - add general guest memory accessors (Izik Eidus)
>> - allow user control over shadow cache size (Izik Eidus)
>> - auto tune shadow cache size with guest memory (Izik Eidus)
>> - allocate guest memory in userspace instead of in kernel (Izik Eidus)
>> - code style fixes (Mike Day, Anthony Liguori)
>> - lapic cleanups (Rusty Russell)
>> - fix acpi interrupt reporting for FreeBSD
>> - fix color problems on certain displays
>> - Red Hat 7.1 support
>> - vmmouse support (Dan Kenigsberg)
>> - fix sdl window caption when keyboard is captured (Dan Kenigsberg)
>> - improve libkvm configure script (Jerone Young)
>> - improve bios compilation support on x86_64 hosts (Laurent Vivier)
>> - fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng
>> Yang)
> 
> when i try to compile it on centos i've got this error (which is not
> happend in kvm-45) :
> ----------------------------------
> iasl -tc -p acpi-dsdt.hex acpi-dsdt.dsl
> make[1]: iasl: Command not found
> ----------------------------------
> where this iasl comes from? and where can i found it? i can't found in
> any package even in external repos.
> 

ok i find it for fedora and recompile it from there.

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.  This is important if you have a mainframe, but also if
> you want to share memory between guests and implement nice features like
> swapping.

we did a quick test against this version and it's turn out the smp
guests are still not working. even if we start only one linux guest with
4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
loading process (if we run more smp guests then they hang earlier, but
different random stage), but it's never reach the end of the kernel so
hang somewhere inside the kernel. and the cpu usage of these process
goes up to until the qemu-kvm processes eat all cpus (ie. 100%). the
strange thing is that the host is running no error on console just these
 and similar are in dmesg:
-------------------------------
Ignoring de-assert INIT to vcpu 1
SIPI to vcpu 1 vector 0x03
SIPI to vcpu 1 vector 0x03
Ignoring de-assert INIT to vcpu 2
SIPI to vcpu 2 vector 0x03
-------------------------------

but the good news that if we run more single cpu guests (both linux and
windows) than it seems to working (at least in the last half an hour:-).
which means that kvm-46 is as usable as kvm-36 for us (which was not the
case with all previous version), but of course this's a very subjective
'fact':-)

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Farkas Levente wrote:
> Avi Kivity wrote:
>   
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.  This is important if you have a mainframe, but also if
>> you want to share memory between guests and implement nice features like
>> swapping.
>>     
>
> we did a quick test against this version and it's turn out the smp
> guests are still not working. even if we start only one linux guest with
> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
> loading process (if we run more smp guests then they hang earlier, but
> different random stage), but it's never reach the end of the kernel so
> hang somewhere inside the kernel. and the cpu usage of these process
> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t


What host cpu are you using?  What guest kernel version?  32-bit or 64-bit?

I have no problems running a 4-way Linux guest here.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>  
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.  This is important if you have a mainframe, but also if
>>> you want to share memory between guests and implement nice features like
>>> swapping.
>>>     
>>
>> we did a quick test against this version and it's turn out the smp
>> guests are still not working. even if we start only one linux guest with
>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>> loading process (if we run more smp guests then they hang earlier, but
>> different random stage), but it's never reach the end of the kernel so
>> hang somewhere inside the kernel. and the cpu usage of these process
>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
> 
> 
> What host cpu are you using?  What guest kernel version?  32-bit or 64-bit?
> 
> I have no problems running a 4-way Linux guest here.

- host:
  - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
  - Intel S3000AHV
  - 8GB RAM
  - CentOS-5
  - kernel-2.6.18-8.1.14.el5 x86_64 64bit
- guest-1:
  - CentOS-5
  - kernel-2.6.18-8.1.14.el5 i386 32bit
- guest-2:
  - CentOS-5
  - kernel-2.6.18-8.1.14.el5 x86_64 64bit
- guest-3:
  - Mandrake-9
  - kernel-2.4.19.16mdk-1-1mdk 32bit
- guest-4:
  - Windows XP Professional 32bit

start the first guest-1 with 4cpu produce the above hang. (and of course
using kvm-46:-)

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Farkas Levente wrote:
>>> we did a quick test against this version and it's turn out the smp
>>> guests are still not working. even if we start only one linux guest with
>>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>>> loading process (if we run more smp guests then they hang earlier, but
>>> different random stage), but it's never reach the end of the kernel so
>>> hang somewhere inside the kernel. and the cpu usage of these process
>>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
>>>       
>> What host cpu are you using?  What guest kernel version?  32-bit or 64-bit?
>>
>> I have no problems running a 4-way Linux guest here.
>>     
>
> - host:
>   - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
>   - Intel S3000AHV
>   - 8GB RAM
>   - CentOS-5
>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
> - guest-1:
>   - CentOS-5
>   - kernel-2.6.18-8.1.14.el5 i386 32bit
> - guest-2:
>   - CentOS-5
>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
> - guest-3:
>   - Mandrake-9
>   - kernel-2.4.19.16mdk-1-1mdk 32bit
> - guest-4:
>   - Windows XP Professional 32bit
>
> start the first guest-1 with 4cpu produce the above hang. (and of course
> using kvm-46:-)
>
>   

Is it the only guest that hangs with -smp 4?  Or all of them?



-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> Farkas Levente wrote:
>>>> we did a quick test against this version and it's turn out the smp
>>>> guests are still not working. even if we start only one linux guest
>>>> with
>>>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>>>> loading process (if we run more smp guests then they hang earlier, but
>>>> different random stage), but it's never reach the end of the kernel so
>>>> hang somewhere inside the kernel. and the cpu usage of these process
>>>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
>>>>       
>>> What host cpu are you using?  What guest kernel version?  32-bit or
>>> 64-bit?
>>>
>>> I have no problems running a 4-way Linux guest here.
>>>     
>>
>> - host:
>>   - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
>>   - Intel S3000AHV
>>   - 8GB RAM
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>> - guest-1:
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 i386 32bit
>> - guest-2:
>>   - CentOS-5
>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>> - guest-3:
>>   - Mandrake-9
>>   - kernel-2.4.19.16mdk-1-1mdk 32bit
>> - guest-4:
>>   - Windows XP Professional 32bit
>>
>> start the first guest-1 with 4cpu produce the above hang. (and of course
>> using kvm-46:-)
>>
>>   
> 
> Is it the only guest that hangs with -smp 4?  Or all of them?

if i start this guest alone it's hang. if i start all guest-{1,2,3,4}
than all linux guest hangs expect windows which runs but see only one
cpu. ok now i try it for you:-) so:

- host + guest-1 -> hang

- host + guest-2 -> hang
in this case i've got a stack trace too on the host, and the host
working 2 more minutes (!?) so i see the top part of the stack
(shift-pageup) but when i try to take a picture the host crash and i can
only see the end:-( but next time i bale to catch it:
-----------------------------------------------
BUG: soft lockup detected on CPU#0!

Call Trace:
 <IRQ>  [<ffffffff800b2c30>] softlockup_tick+0xdb/0xed
 [<ffffffff800933ec>] update_process_times+0x42/0x68
 [<ffffffff80073d61>] smp_local_timer_interrupt+0x23/0x47
 [<ffffffff80074423>] smp_apic_timer_interrupt+0x41/0x47
 [<ffffffff8005bcc2>] apic_timer_interrupt+0x66/0x6c
 <EOI>  [<ffffffff88208aa6>] :kvm:kvm_flush_remote_tlbs+0xfb/0x109
 [<ffffffff88208a95>] :kvm:kvm_flush_remote_tlbs+0xea/0x109
 [<ffffffff8820e0a7>] :kvm:kvm_mmu_pte_write+0x1fc/0x330
 [<ffffffff88207657>] :kvm:kvm_write_guest_page+0x98/0xa3
 [<ffffffff882093fd>] :kvm:emulator_write_emulated_onepage+0x6e/0xce
 [<ffffffff88211a91>] :kvm:x86_emulate_insn+0x2b99/0x3e58
 [<ffffffff8005fc15>] __memset+0x39/0xc0
 [<ffffffff88229404>] :kvm_intel:vmcs_readl+0x17/0x1c
 [<ffffffff88209251>] :kvm:emulate_instruction+0x152/0x290
 [<ffffffff8822bb85>] :kvm_intel:handle_exception+0x170/0x250
 [<ffffffff88209945>] :kvm:kvm_vcpu_ioctl+0x34b/0x10ba
 [<ffffffff88213082>] :kvm:kvm_vcpu_kick+0x34/0x8e
 [<ffffffff8820ae33>] :kvm:kvm_vm_ioctl+0x48a/0x6af
 [<ffffffff800bea1e>] zone_statistics+0x3e/0x6d
 [<ffffffff8000a778>] get_page_from_freelist+0x35d/0x3cf
 [<ffffffff800bea1e>] zone_statistics+0x3e/0x6d
 [<ffffffff8000a778>] get_page_from_freelist+0x35d/0x3cf
 [<ffffffff8000ee4e>] __alloc_pages+0x65/0x2b2
 [<ffffffff8013b1b2>] __next_cpu+0x19/0x28
 [<ffffffff800857cf>] find_busiest_group+0x20d/0x621
 [<ffffffff8013b1b2>] __next_cpu+0x19/0x28
 [<ffffffff80072a51>] smp_send_reschedule+0x4e/0x53
 [<ffffffff80086458>] enqueue_task+0x41/0x56
 [<ffffffff80086494>] __activate_task+0x27/0x39
 [<ffffffff80044d32>] try_to_wake_up+0x407/0x418
 [<ffffffff800850b5>] __wake_up_common+0x3e/0x68
 [<ffffffff8002dd9c>] __wake_up+0x38/0x4f
 [<ffffffff80021b8a>] __up_read+0x19/0x7f
 [<ffffffff8011735a>] avc_has_perm+0x43/0x55
 [<ffffffff80117e91>] inode_has_perm+0x56/0x63
 [<ffffffff80086c37>] default_wake_function+0x0/0xe
 [<ffffffff80117f32>] file_has_perm+0x94/0xa3
 [<ffffffff8003fc5b>] do_ioctl+0x21/0x6b
 [<ffffffff8002fa61>] vfs_ioctl+0x248/0x261
 [<ffffffff8004a267>] sys_ioctl+0x59/0x78
 [<ffffffff8005b2c1>] tracesys+0xd1/0xdc
-----------------------------------------------
i hope shouldn't have to test all other guests:-(
but if i can help you in something more specific let me know:-)




-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Farkas Levente wrote:
> Avi Kivity wrote:
>   
>> Farkas Levente wrote:
>>     
>>>>> we did a quick test against this version and it's turn out the smp
>>>>> guests are still not working. even if we start only one linux guest
>>>>> with
>>>>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>>>>> loading process (if we run more smp guests then they hang earlier, but
>>>>> different random stage), but it's never reach the end of the kernel so
>>>>> hang somewhere inside the kernel. and the cpu usage of these process
>>>>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
>>>>>       
>>>>>           
>>>> What host cpu are you using?  What guest kernel version?  32-bit or
>>>> 64-bit?
>>>>
>>>> I have no problems running a 4-way Linux guest here.
>>>>     
>>>>         
>>> - host:
>>>   - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
>>>   - Intel S3000AHV
>>>   - 8GB RAM
>>>   - CentOS-5
>>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>>> - guest-1:
>>>   - CentOS-5
>>>   - kernel-2.6.18-8.1.14.el5 i386 32bit
>>> - guest-2:
>>>   - CentOS-5
>>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>>> - guest-3:
>>>   - Mandrake-9
>>>   - kernel-2.4.19.16mdk-1-1mdk 32bit
>>> - guest-4:
>>>   - Windows XP Professional 32bit
>>>
>>> start the first guest-1 with 4cpu produce the above hang. (and of course
>>> using kvm-46:-)
>>>
>>>   
>>>       
>> Is it the only guest that hangs with -smp 4?  Or all of them?
>>     
>
> if i start this guest alone it's hang. if i start all guest-{1,2,3,4}
> than all linux guest hangs expect windows which runs but see only one
> cpu. ok now i try it for you:-) so:
>
> - host + guest-1 -> hang
>
> - host + guest-2 -> hang
> in this case i've got a stack trace too on the host, and the host
> working 2 more minutes (!?) so i see the top part of the stack
> (shift-pageup) but when i try to take a picture the host crash and i can
> only see the end:-( but next time i bale to catch it:
> -----------------------------------------------
> BUG: soft lockup detected on CPU#0!
>   

Yunfeng reports that this has been fixed, can you try the latest
snapshot from http://people.qumranet.com/avi/snapshots/?


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Farkas Levente]

Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>   
>>> Farkas Levente wrote:
>>>     
>>>>>> we did a quick test against this version and it's turn out the smp
>>>>>> guests are still not working. even if we start only one linux guest
>>>>>> with
>>>>>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>>>>>> loading process (if we run more smp guests then they hang earlier, but
>>>>>> different random stage), but it's never reach the end of the kernel so
>>>>>> hang somewhere inside the kernel. and the cpu usage of these process
>>>>>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
>>>>>>       
>>>>>>           
>>>>> What host cpu are you using?  What guest kernel version?  32-bit or
>>>>> 64-bit?
>>>>>
>>>>> I have no problems running a 4-way Linux guest here.
>>>>>     
>>>>>         
>>>> - host:
>>>>   - Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz
>>>>   - Intel S3000AHV
>>>>   - 8GB RAM
>>>>   - CentOS-5
>>>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>>>> - guest-1:
>>>>   - CentOS-5
>>>>   - kernel-2.6.18-8.1.14.el5 i386 32bit
>>>> - guest-2:
>>>>   - CentOS-5
>>>>   - kernel-2.6.18-8.1.14.el5 x86_64 64bit
>>>> - guest-3:
>>>>   - Mandrake-9
>>>>   - kernel-2.4.19.16mdk-1-1mdk 32bit
>>>> - guest-4:
>>>>   - Windows XP Professional 32bit
>>>>
>>>> start the first guest-1 with 4cpu produce the above hang. (and of course
>>>> using kvm-46:-)
>>>>
>>>>   
>>>>       
>>> Is it the only guest that hangs with -smp 4?  Or all of them?
>>>     
>> if i start this guest alone it's hang. if i start all guest-{1,2,3,4}
>> than all linux guest hangs expect windows which runs but see only one
>> cpu. ok now i try it for you:-) so:
>>
>> - host + guest-1 -> hang
>>
>> - host + guest-2 -> hang
>> in this case i've got a stack trace too on the host, and the host
>> working 2 more minutes (!?) so i see the top part of the stack
>> (shift-pageup) but when i try to take a picture the host crash and i can
>> only see the end:-( but next time i bale to catch it:
>> -----------------------------------------------
>> BUG: soft lockup detected on CPU#0!
>>   
> 
> Yunfeng reports that this has been fixed, can you try the latest
> snapshot from http://people.qumranet.com/avi/snapshots/?

and the rpms in my repo, but i'd rather wait for kvm-47 since this's a
production server and i'd like to play with it only once a week:-)

-- 
  Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Daniel P. Berrange]

On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.  This is important if you have a mainframe, but also if
> you want to share memory between guests and implement nice features like
> swapping.

Is the memory allocation swappable by default, or still pinned in RAM by
default ?

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Daniel P. Berrange wrote:
> On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote:
>   
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.  This is important if you have a mainframe, but also if
>> you want to share memory between guests and implement nice features like
>> swapping.
>>     
>
> Is the memory allocation swappable by default, or still pinned in RAM by
> default ?
>
>   

It's still not swappable.  That will come in a future release.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Haydn Solomon]

[-- Attachment #1.1: Type: text/plain, Size: 1304 bytes --]

Should we be seeing a mmap file when running guests now or do we have to use
a special flag when running kvm?

On 10/10/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
> Daniel P. Berrange wrote:
> > On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote:
> >
> >> We've now switched to allocating guest memory in userspace rather than
> >> in the kernel.  This is important if you have a mainframe, but also if
> >> you want to share memory between guests and implement nice features
> like
> >> swapping.
> >>
> >
> > Is the memory allocation swappable by default, or still pinned in RAM by
> > default ?
> >
> >
>
> It's still not swappable.  That will come in a future release.
>
>
> --
> error compiling committee.c: too many arguments to function
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>

[-- Attachment #1.2: Type: text/html, Size: 1921 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [ANNOUNCE] kvm-46 release

[Dor Laor]

Haydn Solomon wrote:
> Should we be seeing a mmap file when running guests now or do we have 
> to use a special flag when running kvm?
>
Nope, the default is user space allocation were a regular malloc is used 
for allocating the guest ram from userspace.
The mmap is for future shared memory implementations for parts of the 
guest memory space.
> On 10/10/07, *Avi Kivity* < avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org 
> <mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>> wrote:
>
>     Daniel P. Berrange wrote:
>     > On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote:
>     >
>     >> We've now switched to allocating guest memory in userspace
>     rather than
>     >> in the kernel.  This is important if you have a mainframe, but
>     also if
>     >> you want to share memory between guests and implement nice
>     features like
>     >> swapping.
>     >>
>     >
>     > Is the memory allocation swappable by default, or still pinned
>     in RAM by
>     > default ?
>     >
>     >
>
>     It's still not swappable.  That will come in a future release.
>
>
>     --
>     error compiling committee.c: too many arguments to function
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Splunk Inc.
>     Still grepping through log files to find problems?  Stop.
>     Now Search log events and configuration files using AJAX and a
>     browser.
>     Download your FREE copy of Splunk now >> http://get.splunk.com/
>     _______________________________________________
>     kvm-devel mailing list
>     kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>     <mailto:kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>     https://lists.sourceforge.net/lists/listinfo/kvm-devel
>     <https://lists.sourceforge.net/lists/listinfo/kvm-devel>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Haydn Solomon]

[-- Attachment #1.1: Type: text/plain, Size: 2786 bytes --]

Thanks for clearing that up.


On 10/10/07, Dor Laor <dor.laor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Haydn Solomon wrote:
> > Should we be seeing a mmap file when running guests now or do we have
> > to use a special flag when running kvm?
> >
> Nope, the default is user space allocation were a regular malloc is used
> for allocating the guest ram from userspace.
> The mmap is for future shared memory implementations for parts of the
> guest memory space.
> > On 10/10/07, *Avi Kivity* < avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org
> > <mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>> wrote:
> >
> >     Daniel P. Berrange wrote:
> >     > On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote:
> >     >
> >     >> We've now switched to allocating guest memory in userspace
> >     rather than
> >     >> in the kernel.  This is important if you have a mainframe, but
> >     also if
> >     >> you want to share memory between guests and implement nice
> >     features like
> >     >> swapping.
> >     >>
> >     >
> >     > Is the memory allocation swappable by default, or still pinned
> >     in RAM by
> >     > default ?
> >     >
> >     >
> >
> >     It's still not swappable.  That will come in a future release.
> >
> >
> >     --
> >     error compiling committee.c: too many arguments to function
> >
> >
> >
> -------------------------------------------------------------------------
> >     This SF.net email is sponsored by: Splunk Inc.
> >     Still grepping through log files to find problems?  Stop.
> >     Now Search log events and configuration files using AJAX and a
> >     browser.
> >     Download your FREE copy of Splunk now >> http://get.splunk.com/
> >     _______________________________________________
> >     kvm-devel mailing list
> >     kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >     <mailto:kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> >     https://lists.sourceforge.net/lists/listinfo/kvm-devel
> >     <https://lists.sourceforge.net/lists/listinfo/kvm-devel>
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > kvm-devel mailing list
> > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
> >
>
>

[-- Attachment #1.2: Type: text/html, Size: 4777 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [ANNOUNCE] kvm-46 release

[Gerd Hoffmann]

Avi Kivity wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.

Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
use that.  If I want to back vm memory with a file mapping, how can I do
that?

cheers,
  Gerd


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Avi Kivity]

Gerd Hoffmann wrote:
> Avi Kivity wrote:
>   
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.
>>     
>
> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
> use that.  If I want to back vm memory with a file mapping, how can I do
> that?
>   

kvmctl.h doesn't expose an API for that currently, though is should be
fairly trivial to do so.  The kernel API is straightforward: take this
bunch of memory and present it to a guest at some address.  The kernel
doesn't care if the memory came from a file mmap() or some other source.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> Avi Kivity wrote:
>>   
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.
>>>     
>> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
>> use that.  If I want to back vm memory with a file mapping, how can I do
>> that?
>>   
> 
> kvmctl.h doesn't expose an API for that currently, though is should be
> fairly trivial to do so.

Something like this? (compiles, not tested yet).

cheers,
  Gerd


[-- Attachment #2: kvm-user-memory.diff --]
[-- Type: text/x-patch, Size: 3126 bytes --]

* make kvm_create() skip all memory setup in case phys_mem_bytes == 0
* add kvm_register_userspace_phys_mem() to register any userspace memory
  as guest physical memory.

Signed-off-by: Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 user/kvmctl.c |   53 +++++++++++++++++++++++++++++++++++++++++------------
 user/kvmctl.h |    3 +++
 2 files changed, 44 insertions(+), 12 deletions(-)

Index: kvm-46/user/kvmctl.c
===================================================================
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -443,20 +443,22 @@ int kvm_create(kvm_context_t kvm, unsign
 	}
 	kvm->vm_fd = fd;
 
-	r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
-	if (r > 0)
-		r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
-	else
-		r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
-	if (r < 0)
-		return r;
+	if (phys_mem_bytes) {
+		r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
+		if (r > 0)
+			r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
+		else
+			r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
+		if (r < 0)
+			return r;
 
-        zfd = open("/dev/zero", O_RDONLY);
-        mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
-             MAP_PRIVATE|MAP_FIXED, zfd, 0);
-        close(zfd);
+	        zfd = open("/dev/zero", O_RDONLY);
+	        mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
+	             MAP_PRIVATE|MAP_FIXED, zfd, 0);
+	        close(zfd);
 
-	kvm->physical_memory = *vm_mem;
+		kvm->physical_memory = *vm_mem;
+	}
 
 	kvm->irqchip_in_kernel = 0;
 	if (!kvm->no_irqchip_creation) {
@@ -558,6 +560,33 @@ void *kvm_create_phys_mem(kvm_context_t 
 								log, writable);
 }
 
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log)
+{
+	int r;
+	struct kvm_userspace_memory_region memory = {
+		.slot = slot,
+		.memory_size = len,
+		.guest_phys_addr = phys_start,
+		.userspace_addr = (intptr_t)userspace_addr,
+		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+	};
+
+	if (!kvm->physical_memory)
+		kvm->physical_memory = userspace_addr - phys_start;
+
+	r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+	if (r == -1) {
+		fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+		return -1;
+	}
+
+	kvm_userspace_memory_region_save_params(kvm, &memory);
+
+	return 0;
+}
+
 /* destroy/free a whole slot.
  * phys_start, len and slot are the params passed to kvm_create_phys_mem()
  */
Index: kvm-46/user/kvmctl.h
===================================================================
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -404,6 +404,9 @@ void *kvm_create_phys_mem(kvm_context_t,
 			  unsigned long len, int slot, int log, int writable);
 void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start, 
 			  unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log);
 int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
 
 

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [ANNOUNCE] kvm-46 release

[Gerd Hoffmann]

Gerd Hoffmann wrote:

> Something like this? (compiles, not tested yet).

Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".

cheers,
  Gerd

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Izik Eidus]

On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
> 
> > Something like this? (compiles, not tested yet).
> 
> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".

try use slot bigger bigger than 5 and smaller than 8
> cheers,
>   Gerd
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Gerd Hoffmann]

Izik Eidus wrote:
> On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
>> Gerd Hoffmann wrote:
>>
>>> Something like this? (compiles, not tested yet).
>> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
> 
> try use slot bigger bigger than 5 and smaller than 8

It doesn't come that far, kvm_create(&foo, 0, NULL) fails, seems doing
vcpu_create() before memory setup doesn't work.

cheers,
  Gerd



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Izik Eidus]

On Mon, 2007-10-15 at 13:15 +0200, Gerd Hoffmann wrote:
> Izik Eidus wrote:
> > On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
> >> Gerd Hoffmann wrote:
> >>
> >>> Something like this? (compiles, not tested yet).
> >> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
> > 
> > try use slot bigger bigger than 5 and smaller than 8
> 
> It doesn't come that far, kvm_create(&foo, 0, NULL) fails, seems doing
> vcpu_create() before memory setup doesn't work.
> 
> cheers,
>   Gerd
> 
> 
can you send me your kvmctl.c file so i will look at it?
it is somewhat hard to me understand how you did the things that way


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [ANNOUNCE] kvm-46 release

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

Izik Eidus wrote:
> can you send me your kvmctl.c file so i will look at it?
> it is somewhat hard to me understand how you did the things that way

I'm trying to back a vm with memory coming from a file map, see patch
attached against kvm-46 (was also attached earlier in this thread).

I've made kvm_create() optionally skip the memory setup, so I can create
my own later on.  That doesn't work though because creating the vcpu
fails then.

cheers,
  Gerd

[-- Attachment #2: kvm-user-memory.diff --]
[-- Type: text/x-patch, Size: 3126 bytes --]

* make kvm_create() skip all memory setup in case phys_mem_bytes == 0
* add kvm_register_userspace_phys_mem() to register any userspace memory
  as guest physical memory.

Signed-off-by: Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 user/kvmctl.c |   53 +++++++++++++++++++++++++++++++++++++++++------------
 user/kvmctl.h |    3 +++
 2 files changed, 44 insertions(+), 12 deletions(-)

Index: kvm-46/user/kvmctl.c
===================================================================
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -443,20 +443,22 @@ int kvm_create(kvm_context_t kvm, unsign
 	}
 	kvm->vm_fd = fd;
 
-	r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
-	if (r > 0)
-		r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
-	else
-		r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
-	if (r < 0)
-		return r;
+	if (phys_mem_bytes) {
+		r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
+		if (r > 0)
+			r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
+		else
+			r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
+		if (r < 0)
+			return r;
 
-        zfd = open("/dev/zero", O_RDONLY);
-        mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
-             MAP_PRIVATE|MAP_FIXED, zfd, 0);
-        close(zfd);
+	        zfd = open("/dev/zero", O_RDONLY);
+	        mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
+	             MAP_PRIVATE|MAP_FIXED, zfd, 0);
+	        close(zfd);
 
-	kvm->physical_memory = *vm_mem;
+		kvm->physical_memory = *vm_mem;
+	}
 
 	kvm->irqchip_in_kernel = 0;
 	if (!kvm->no_irqchip_creation) {
@@ -558,6 +560,33 @@ void *kvm_create_phys_mem(kvm_context_t 
 								log, writable);
 }
 
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log)
+{
+	int r;
+	struct kvm_userspace_memory_region memory = {
+		.slot = slot,
+		.memory_size = len,
+		.guest_phys_addr = phys_start,
+		.userspace_addr = (intptr_t)userspace_addr,
+		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+	};
+
+	if (!kvm->physical_memory)
+		kvm->physical_memory = userspace_addr - phys_start;
+
+	r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+	if (r == -1) {
+		fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+		return -1;
+	}
+
+	kvm_userspace_memory_region_save_params(kvm, &memory);
+
+	return 0;
+}
+
 /* destroy/free a whole slot.
  * phys_start, len and slot are the params passed to kvm_create_phys_mem()
  */
Index: kvm-46/user/kvmctl.h
===================================================================
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -404,6 +404,9 @@ void *kvm_create_phys_mem(kvm_context_t,
 			  unsigned long len, int slot, int log, int writable);
 void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start, 
 			  unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log);
 int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
 
 

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Gerd Hoffmann wrote:
> I've made kvm_create() optionally skip the memory setup, so I can create
> my own later on.  That doesn't work though because creating the vcpu
> fails then.

Ugh, vmx grabs last 4 pages from slot 0 (looks like for real mode
emulation).  Thus memory must exist before creating the vcpu.  Which
makes fitting filemap-backed memory into the current libkvm init
procedure a bit difficuilt.

I've decided to split the kvm_create() into a bunch of pieces which can
be called as needed, so I can first create the vm, then do my custom
memory setup, then create the vcpu without making vmx unhappy ...

cheers,
  Gerd


[-- Attachment #2: kvm-user-memory.diff --]
[-- Type: text/x-patch, Size: 3997 bytes --]

* split kvm_create() into smaller pieces which can be individually
  called if needed.
* add kvm_register_userspace_phys_mem() function.
---
 user/kvmctl.c |   61 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 user/kvmctl.h |    8 +++++++
 2 files changed, 64 insertions(+), 5 deletions(-)

Index: kvm-46/user/kvmctl.c
===================================================================
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -427,12 +427,9 @@ int kvm_alloc_userspace_memory(kvm_conte
 	return 0;
 }
 
-int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+int kvm_create_vm(kvm_context_t kvm)
 {
-	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
 	int fd = kvm->fd;
-	int zfd;
-	int r;
 
 	kvm->vcpu_fd[0] = -1;
 
@@ -442,6 +439,15 @@ int kvm_create(kvm_context_t kvm, unsign
 		return -1;
 	}
 	kvm->vm_fd = fd;
+	return 0;
+}
+
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+				void **vm_mem)
+{
+	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
+	int zfd;
+	int r;
 
 	r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
 	if (r > 0)
@@ -457,18 +463,37 @@ int kvm_create(kvm_context_t kvm, unsign
         close(zfd);
 
 	kvm->physical_memory = *vm_mem;
+	return 0;
+}
+
+void kvm_create_irqchip(kvm_context_t kvm)
+{
+	int r;
 
 	kvm->irqchip_in_kernel = 0;
 	if (!kvm->no_irqchip_creation) {
 		r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_IRQCHIP);
 		if (r > 0) {	/* kernel irqchip supported */
-			r = ioctl(fd, KVM_CREATE_IRQCHIP);
+			r = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
 			if (r >= 0)
 				kvm->irqchip_in_kernel = 1;
 			else
 				printf("Create kernel PIC irqchip failed\n");
 		}
 	}
+}
+
+int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+{
+	int r;
+
+	r = kvm_create_vm(kvm);
+	if (r < 0)
+		return r;
+	r = kvm_create_default_phys_mem(kvm, phys_mem_bytes, vm_mem);
+	if (r < 0)
+		return r;
+	kvm_create_irqchip(kvm);
 	r = kvm_create_vcpu(kvm, 0);
 	if (r < 0)
 		return r;
@@ -558,6 +583,32 @@ void *kvm_create_phys_mem(kvm_context_t 
 								log, writable);
 }
 
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log)
+{
+	struct kvm_userspace_memory_region memory = {
+		.slot = slot,
+		.memory_size = len,
+		.guest_phys_addr = phys_start,
+		.userspace_addr = (intptr_t)userspace_addr,
+		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+	};
+	int r;
+
+	if (!kvm->physical_memory)
+		kvm->physical_memory = userspace_addr - phys_start;
+
+	r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+	if (r == -1) {
+		fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+		return -1;
+	}
+
+	kvm_userspace_memory_region_save_params(kvm, &memory);
+        return 0;
+}
+
 /* destroy/free a whole slot.
  * phys_start, len and slot are the params passed to kvm_create_phys_mem()
  */
Index: kvm-46/user/kvmctl.h
===================================================================
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -137,6 +137,11 @@ int kvm_get_shadow_pages(kvm_context_t k
 int kvm_create(kvm_context_t kvm,
 	       unsigned long phys_mem_bytes,
 	       void **phys_mem);
+int kvm_create_vm(kvm_context_t kvm);
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+				void **vm_mem);
+void kvm_create_irqchip(kvm_context_t kvm);
+
 /*!
  * \brief Create a new virtual cpu
  *
@@ -404,6 +409,9 @@ void *kvm_create_phys_mem(kvm_context_t,
 			  unsigned long len, int slot, int log, int writable);
 void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start, 
 			  unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log);
 int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
 
 

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [patch] kvmctl.c: allow custom memory setup.

[Izik Eidus]

Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>   
>> I've made kvm_create() optionally skip the memory setup, so I can create
>> my own later on.  That doesn't work though because creating the vcpu
>> fails then.
>>     
>
> Ugh, vmx grabs last 4 pages from slot 0 (looks like for real mode
> emulation).  Thus memory must exist before creating the vcpu.  Which
> makes fitting filemap-backed memory into the current libkvm init
> procedure a bit difficuilt.
>
> I've decided to split the kvm_create() into a bunch of pieces which can
> be called as needed, so I can first create the vm, then do my custom
> memory setup, then create the vcpu without making vmx unhappy ...
>
> cheers,
>   Gerd
>
>   
hi,
why not making kvm_create_userspace_memory() recive a pointer to a 
userspace allocated memory (that was allocated from file or from normal 
malloc)
and make all the changes before kvm_create_userspace_memory() get called?
this way you just need to remove the memory allocation out of 
kvm_create_userspace_memory() and alloc as you want.

what you think about that?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Izik Eidus]

Izik Eidus wrote:
> Gerd Hoffmann wrote:
>> Gerd Hoffmann wrote:
>>  
>>> I've made kvm_create() optionally skip the memory setup, so I can 
>>> create
>>> my own later on.  That doesn't work though because creating the vcpu
>>> fails then.
>>>     
>>
>> Ugh, vmx grabs last 4 pages from slot 0 (looks like for real mode
>> emulation).  Thus memory must exist before creating the vcpu.  Which
>> makes fitting filemap-backed memory into the current libkvm init
>> procedure a bit difficuilt.
>>
>> I've decided to split the kvm_create() into a bunch of pieces which can
>> be called as needed, so I can first create the vm, then do my custom
>> memory setup, then create the vcpu without making vmx unhappy ...
>>
>> cheers,
>>   Gerd
>>
>>   
> hi,
> why not making kvm_create_userspace_memory() recive a pointer to a 
> userspace allocated memory (that was allocated from file or from 
> normal malloc)
> and make all the changes before kvm_create_userspace_memory() get called?
> this way you just need to remove the memory allocation out of 
> kvm_create_userspace_memory() and alloc as you want.
>
> what you think about that?
>
that would bring the ability to qemu allocate the memory and send us the 
pointer to the allocated memory.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

Izik Eidus wrote:
> hi,
> why not making kvm_create_userspace_memory() recive a pointer to a
> userspace allocated memory (that was allocated from file or from normal
> malloc)
> and make all the changes before kvm_create_userspace_memory() get called?

I don't see how I can pass a pointer to kvm_create_userspace_memory()
via kvm_create() without breaking the libkvm interface.  There is no
flags field or similar which could be used to signal "vm_mem is a valid
pointer, please use that instead of mmap()'ing anonymous memory".

Oh, and I also don't want special the treatment of the 0xa0000 ->
0xfffff memory window.

cheers,
  Gerd


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Dor Laor]

Gerd Hoffmann wrote:
>
> Izik Eidus wrote:
> > hi,
> > why not making kvm_create_userspace_memory() recive a pointer to a
> > userspace allocated memory (that was allocated from file or from normal
> > malloc)
> > and make all the changes before kvm_create_userspace_memory() get 
> called?
>
> I don't see how I can pass a pointer to kvm_create_userspace_memory()
> via kvm_create() without breaking the libkvm interface.  There is no
> flags field or similar which could be used to signal "vm_mem is a valid
> pointer, please use that instead of mmap()'ing anonymous memory".
>
There is no need to keep binary compat to libkvm as long as it is linked 
statically.
We only need to keep binary compat with the kernel.
>
> Oh, and I also don't want special the treatment of the 0xa0000 ->
> 0xfffff memory window.
>
> cheers,
>   Gerd
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

Dor Laor wrote:
> Gerd Hoffmann wrote:
>> I don't see how I can pass a pointer to kvm_create_userspace_memory()
>> via kvm_create() without breaking the libkvm interface.  There is no
>> flags field or similar which could be used to signal "vm_mem is a valid
>> pointer, please use that instead of mmap()'ing anonymous memory".

> There is no need to keep binary compat to libkvm as long as it is linked
> statically.

What about source compatibility?

cheers,
  Gerd



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Izik Eidus]

On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
> Dor Laor wrote:
> > Gerd Hoffmann wrote:
> >> I don't see how I can pass a pointer to kvm_create_userspace_memory()
> >> via kvm_create() without breaking the libkvm interface.  There is no
> >> flags field or similar which could be used to signal "vm_mem is a valid
> >> pointer, please use that instead of mmap()'ing anonymous memory".
> 
> > There is no need to keep binary compat to libkvm as long as it is linked
> > statically.
> 
> What about source compatibility?
> 
> cheers,
>   Gerd
> 
> 
anyone who use kvmctl, should not call kvm_create_userspace_memory
directly,

instead should call kvm_create()...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Avi Kivity]

Izik Eidus wrote:
> On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
>   
>> Dor Laor wrote:
>>     
>>> Gerd Hoffmann wrote:
>>>       
>>>> I don't see how I can pass a pointer to kvm_create_userspace_memory()
>>>> via kvm_create() without breaking the libkvm interface.  There is no
>>>> flags field or similar which could be used to signal "vm_mem is a valid
>>>> pointer, please use that instead of mmap()'ing anonymous memory".
>>>>         
>>> There is no need to keep binary compat to libkvm as long as it is linked
>>> statically.
>>>       
>> What about source compatibility?
>>
>> cheers,
>>   Gerd
>>
>>
>>     
> anyone who use kvmctl, should not call kvm_create_userspace_memory
> directly,
>
> instead should call kvm_create()...
>
>   

Why not have an API for creating memory slots?  It allows much more 
flexibility and is more in line with what qemu wants.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Avi Kivity wrote:
> Izik Eidus wrote:
>> On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
>> 
>>>>> I don't see how I can pass a pointer to
>>>>> kvm_create_userspace_memory() via kvm_create() without
>>>>> breaking the libkvm interface.  There is no flags field or
>>>>> similar which could be used to signal "vm_mem is a valid 
>>>>> pointer, please use that instead of mmap()'ing anonymous
>>>>> memory".
>>>>> 
>>>> There is no need to keep binary compat to libkvm as long as it
>>>> is linked statically.

>> anyone who use kvmctl, should not call kvm_create_userspace_memory 
>> directly, instead should call kvm_create()...

I'm talking about the kvm_create() interface, dammit.  Sure I can modify
kvm_create_userspace_memory() without breaking anyone as this isn't part
of the public (kvmctl.h) interface.  That doesn't buy us much though.
I'd have to pass the pointer to kvm_create() somehow so it can be passed
down to kvm_create_userspace_memory().  I can't without breaking the
public library interface though.

> Why not have an API for creating memory slots?  It allows much more 
> flexibility and is more in line with what qemu wants.

This *is* what the patch does.  It adds a function to add a
userspace-memory-backed memory slot: kvm_register_userspace_phys_mem().

That alone doesn't cut it though as there are some more constrains:

 * kvm_create() builds a standard memory layout, which I want be able
   to skip.
 * kvm_create() fails to create a vcpu in case no memory is available,
   which makes simple approach to just ask kvm_create() for 0 bytes
   physical memory for the guest unusable.

Thats why I went the route to additionally split the job kvm_create()
does into multiple, individually callable pieces.  So I can first create
the vm, then create my custom memory slots (instead of the standard
setup built by kvm_create_userspace_memory()), then create the vcpu.

cheers,
  Gerd

ps: patch attached again for reference.

[-- Attachment #2: kvm-user-memory.diff --]
[-- Type: text/x-patch, Size: 3997 bytes --]

* split kvm_create() into smaller pieces which can be individually
  called if needed.
* add kvm_register_userspace_phys_mem() function.
---
 user/kvmctl.c |   61 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 user/kvmctl.h |    8 +++++++
 2 files changed, 64 insertions(+), 5 deletions(-)

Index: kvm-46/user/kvmctl.c
===================================================================
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -427,12 +427,9 @@ int kvm_alloc_userspace_memory(kvm_conte
 	return 0;
 }
 
-int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+int kvm_create_vm(kvm_context_t kvm)
 {
-	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
 	int fd = kvm->fd;
-	int zfd;
-	int r;
 
 	kvm->vcpu_fd[0] = -1;
 
@@ -442,6 +439,15 @@ int kvm_create(kvm_context_t kvm, unsign
 		return -1;
 	}
 	kvm->vm_fd = fd;
+	return 0;
+}
+
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+				void **vm_mem)
+{
+	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
+	int zfd;
+	int r;
 
 	r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
 	if (r > 0)
@@ -457,18 +463,37 @@ int kvm_create(kvm_context_t kvm, unsign
         close(zfd);
 
 	kvm->physical_memory = *vm_mem;
+	return 0;
+}
+
+void kvm_create_irqchip(kvm_context_t kvm)
+{
+	int r;
 
 	kvm->irqchip_in_kernel = 0;
 	if (!kvm->no_irqchip_creation) {
 		r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_IRQCHIP);
 		if (r > 0) {	/* kernel irqchip supported */
-			r = ioctl(fd, KVM_CREATE_IRQCHIP);
+			r = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
 			if (r >= 0)
 				kvm->irqchip_in_kernel = 1;
 			else
 				printf("Create kernel PIC irqchip failed\n");
 		}
 	}
+}
+
+int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+{
+	int r;
+
+	r = kvm_create_vm(kvm);
+	if (r < 0)
+		return r;
+	r = kvm_create_default_phys_mem(kvm, phys_mem_bytes, vm_mem);
+	if (r < 0)
+		return r;
+	kvm_create_irqchip(kvm);
 	r = kvm_create_vcpu(kvm, 0);
 	if (r < 0)
 		return r;
@@ -558,6 +583,32 @@ void *kvm_create_phys_mem(kvm_context_t 
 								log, writable);
 }
 
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log)
+{
+	struct kvm_userspace_memory_region memory = {
+		.slot = slot,
+		.memory_size = len,
+		.guest_phys_addr = phys_start,
+		.userspace_addr = (intptr_t)userspace_addr,
+		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+	};
+	int r;
+
+	if (!kvm->physical_memory)
+		kvm->physical_memory = userspace_addr - phys_start;
+
+	r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+	if (r == -1) {
+		fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+		return -1;
+	}
+
+	kvm_userspace_memory_region_save_params(kvm, &memory);
+        return 0;
+}
+
 /* destroy/free a whole slot.
  * phys_start, len and slot are the params passed to kvm_create_phys_mem()
  */
Index: kvm-46/user/kvmctl.h
===================================================================
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -137,6 +137,11 @@ int kvm_get_shadow_pages(kvm_context_t k
 int kvm_create(kvm_context_t kvm,
 	       unsigned long phys_mem_bytes,
 	       void **phys_mem);
+int kvm_create_vm(kvm_context_t kvm);
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+				void **vm_mem);
+void kvm_create_irqchip(kvm_context_t kvm);
+
 /*!
  * \brief Create a new virtual cpu
  *
@@ -404,6 +409,9 @@ void *kvm_create_phys_mem(kvm_context_t,
 			  unsigned long len, int slot, int log, int writable);
 void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start, 
 			  unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log);
 int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
 
 

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [patch] kvmctl.c: allow custom memory setup.

[Avi Kivity]

Gerd Hoffmann wrote:
>
>>> anyone who use kvmctl, should not call kvm_create_userspace_memory 
>>> directly, instead should call kvm_create()...
>>>       
>
> I'm talking about the kvm_create() interface, dammit.  Sure I can modify
> kvm_create_userspace_memory() without breaking anyone as this isn't part
> of the public (kvmctl.h) interface.  That doesn't buy us much though.
> I'd have to pass the pointer to kvm_create() somehow so it can be passed
> down to kvm_create_userspace_memory().  I can't without breaking the
> public library interface though.
>
>   

Break it.  It has just one user, our qemu, which is included in the same 
package.

We will freeze the lib kvm ABI once we have merged our changes into 
upstream qemu.  But that won't happen unless we get a sane interface for 
that library (the current interface is not acceptable).

>> Why not have an API for creating memory slots?  It allows much more 
>> flexibility and is more in line with what qemu wants.
>>     
>
> This *is* what the patch does.  It adds a function to add a
> userspace-memory-backed memory slot: kvm_register_userspace_phys_mem().
>
> That alone doesn't cut it though as there are some more constrains:
>
>  * kvm_create() builds a standard memory layout, which I want be able
>    to skip.
>   

kvm_create() should not be creating memory.

>  * kvm_create() fails to create a vcpu in case no memory is available,
>    which makes simple approach to just ask kvm_create() for 0 bytes
>    physical memory for the guest unusable.
>   

kvm_create() should not be creating vcpus.


> Thats why I went the route to additionally split the job kvm_create()
> does into multiple, individually callable pieces.  So I can first create
> the vm, then create my custom memory slots (instead of the standard
> setup built by kvm_create_userspace_memory()), then create the vcpu.
>   

That's exactly what's needed.


The patch looks good, except that I wouldn't export 
kvm_create_default_phys_mem().  Let qemu do the hard work instead.  Once 
qemu switches to the new interface, we can remove kvm_create().

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

  Hi,

> Break it.  It has just one user, our qemu, which is included in the same
> package.

No, I'm hacking up one more user ;)

But maybe I'm better off shipping a private copy of kvmctl.c as long as
the library interface isn't finalized yet and subject to change.

>> Thats why I went the route to additionally split the job kvm_create()
>> does into multiple, individually callable pieces.  So I can first create
>> the vm, then create my custom memory slots (instead of the standard
>> setup built by kvm_create_userspace_memory()), then create the vcpu.
>>   
> 
> That's exactly what's needed.
> 
> The patch looks good, except that I wouldn't export
> kvm_create_default_phys_mem().

Fine with me.  If you one uses the splitted versions, then for creating
a non-default memory layout, so there is no point in exporting that one.

Should I send an updated patch or do you just drop these lines when merging?

cheers,
  Gerd



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Avi Kivity]

Gerd Hoffmann wrote:
>   Hi,
>
>   
>> Break it.  It has just one user, our qemu, which is included in the same
>> package.
>>     
>
> No, I'm hacking up one more user ;)
>
>   

Nice.  What will it do?

> But maybe I'm better off shipping a private copy of kvmctl.c as long as
> the library interface isn't finalized yet and subject to change.
>
>   

Yes.  Patches to improve libkvm's interface so we can decouple it from 
qemu will be most welcome.

>>> Thats why I went the route to additionally split the job kvm_create()
>>> does into multiple, individually callable pieces.  So I can first create
>>> the vm, then create my custom memory slots (instead of the standard
>>> setup built by kvm_create_userspace_memory()), then create the vcpu.
>>>   
>>>       
>> That's exactly what's needed.
>>
>> The patch looks good, except that I wouldn't export
>> kvm_create_default_phys_mem().
>>     
>
> Fine with me.  If you one uses the splitted versions, then for creating
> a non-default memory layout, so there is no point in exporting that one.
>
> Should I send an updated patch or do you just drop these lines when merging?
>   

Please send a rebased and retested patch.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [patch] kvmctl.c: allow custom memory setup.

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> No, I'm hacking up one more user ;)
> 
> Nice.  What will it do?

Run xenified guest kernels without Xen.

>> Should I send an updated patch or do you just drop these lines when
>> merging?
> 
> Please send a rebased and retested patch.

Oh, -47 is there.  Updated patch attached.

cheers,
  Gerd

[-- Attachment #2: kvm.diff --]
[-- Type: text/x-patch, Size: 3659 bytes --]

diff -up ./kvmctl.h.upstream ./kvmctl.h
--- ./kvmctl.h.upstream	2007-10-18 17:09:06.000000000 +0200
+++ ./kvmctl.h	2007-10-18 17:09:11.000000000 +0200
@@ -146,6 +146,9 @@ int kvm_get_shadow_pages(kvm_context_t k
 int kvm_create(kvm_context_t kvm,
 	       unsigned long phys_mem_bytes,
 	       void **phys_mem);
+int kvm_create_vm(kvm_context_t kvm);
+void kvm_create_irqchip(kvm_context_t kvm);
+
 /*!
  * \brief Create a new virtual cpu
  *
@@ -413,6 +416,9 @@ void *kvm_create_phys_mem(kvm_context_t,
 			  unsigned long len, int slot, int log, int writable);
 void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start, 
 			  unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log);
 int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
 
 
diff -up ./kvmctl.c.upstream ./kvmctl.c
--- ./kvmctl.c.upstream	2007-10-18 17:08:57.000000000 +0200
+++ ./kvmctl.c	2007-10-18 17:18:53.000000000 +0200
@@ -436,12 +436,9 @@ int kvm_alloc_userspace_memory(kvm_conte
 
 #endif
 
-int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+int kvm_create_vm(kvm_context_t kvm)
 {
-	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
 	int fd = kvm->fd;
-	int zfd;
-	int r;
 
 	kvm->vcpu_fd[0] = -1;
 
@@ -451,6 +448,15 @@ int kvm_create(kvm_context_t kvm, unsign
 		return -1;
 	}
 	kvm->vm_fd = fd;
+	return 0;
+}
+
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+				void **vm_mem)
+{
+	unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
+	int zfd;
+	int r;
 
 #ifdef KVM_CAP_USER_MEMORY
 	r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
@@ -468,13 +474,19 @@ int kvm_create(kvm_context_t kvm, unsign
         close(zfd);
 
 	kvm->physical_memory = *vm_mem;
+	return 0;
+}
+
+void kvm_create_irqchip(kvm_context_t kvm)
+{
+	int r;
 
 	kvm->irqchip_in_kernel = 0;
 #ifdef KVM_CAP_IRQCHIP
 	if (!kvm->no_irqchip_creation) {
 		r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_IRQCHIP);
 		if (r > 0) {	/* kernel irqchip supported */
-			r = ioctl(fd, KVM_CREATE_IRQCHIP);
+			r = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
 			if (r >= 0)
 				kvm->irqchip_in_kernel = 1;
 			else
@@ -482,6 +494,19 @@ int kvm_create(kvm_context_t kvm, unsign
 		}
 	}
 #endif
+}
+
+int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+{
+	int r;
+	
+	r = kvm_create_vm(kvm);
+	if (r < 0)
+	        return r;
+	r = kvm_create_default_phys_mem(kvm, phys_mem_bytes, vm_mem);
+	if (r < 0)
+	        return r;
+	kvm_create_irqchip(kvm);
 	r = kvm_create_vcpu(kvm, 0);
 	if (r < 0)
 		return r;
@@ -577,6 +602,32 @@ void *kvm_create_phys_mem(kvm_context_t 
 								log, writable);
 }
 
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+			unsigned long phys_start, void *userspace_addr,
+			unsigned long len, int slot, int log)
+{
+	struct kvm_userspace_memory_region memory = {
+		.slot = slot,
+		.memory_size = len,
+		.guest_phys_addr = phys_start,
+		.userspace_addr = (intptr_t)userspace_addr,
+		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+	};
+	int r;
+
+	if (!kvm->physical_memory)
+		kvm->physical_memory = userspace_addr - phys_start;
+
+	r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+	if (r == -1) {
+		fprintf(stderr, "create_userspace_phys_mem: %s\n", strerror(errno));
+		return -1;
+	}
+
+	kvm_userspace_memory_region_save_params(kvm, &memory);
+        return 0;
+}
+
 /* destroy/free a whole slot.
  * phys_start, len and slot are the params passed to kvm_create_phys_mem()
  */

[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [patch] kvmctl.c: allow custom memory setup.

[Avi Kivity]

Gerd Hoffmann wrote:
>
>>> Should I send an updated patch or do you just drop these lines when
>>> merging?
>>>       
>> Please send a rebased and retested patch.
>>     
>
> Oh, -47 is there.  Updated patch attached.
>
>   

Applied.  But please:

- always supply the changelog comment so I don't have to hunt for it
- base diffs so they can be applied from the base directory with patch 
-p1 (this one was -p0 against the user/ directory).  in general 'git 
diff' (or 'git format-patch' produces the best results with a minimum of 
fuss.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/