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
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.
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 interf
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
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 is
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
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
f
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
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 m
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 do
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_c
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 (lo
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
> emulati
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
14 matches
Mail list logo
