On 2012-06-13 14:33, Alexander Graf wrote:
> On 06/13/2012 01:41 PM, Jan Kiszka wrote:
>> On 2012-06-13 13:27, Christian Borntraeger wrote:
>>> On 13/06/12 12:58, Jan Kiszka wrote:
> Thinking about this a bit more, how about
>
> } else if (!kvm_arch_vmalloc(size,&new_block->host)) {
>>>
On 06/13/2012 01:41 PM, Jan Kiszka wrote:
On 2012-06-13 13:27, Christian Borntraeger wrote:
On 13/06/12 12:58, Jan Kiszka wrote:
Thinking about this a bit more, how about
} else if (!kvm_arch_vmalloc(size,&new_block->host)) {
}
I like that. Of course, we have to have a generic kvm_arch_vmal
On 2012-06-13 13:27, Christian Borntraeger wrote:
> On 13/06/12 12:58, Jan Kiszka wrote:
>>> Thinking about this a bit more, how about
>>>
>>> } else if (!kvm_arch_vmalloc(size, &new_block->host)) {
>>>
>>> }
>>>
>
> I like that. Of course, we have to have a generic kvm_arch_vmalloc
> implementa
On 13/06/12 12:58, Jan Kiszka wrote:
>> Thinking about this a bit more, how about
>>
>> } else if (!kvm_arch_vmalloc(size, &new_block->host)) {
>>
>> }
>>
I like that. Of course, we have to have a generic kvm_arch_vmalloc
implementation
then.
>> Then the arch specific code could do the check an
On 2012-06-13 12:54, Alexander Graf wrote:
> On 06/13/2012 12:30 PM, Jan Kiszka wrote:
>> On 2012-06-12 14:12, Alexander Graf wrote:
>>> On 06/12/2012 02:02 PM, Christian Borntraeger wrote:
On 12/06/12 13:57, Alexander Graf wrote:
> Since it lives in an s390 specific branch, the function n
On 06/13/2012 12:30 PM, Jan Kiszka wrote:
On 2012-06-12 14:12, Alexander Graf wrote:
On 06/12/2012 02:02 PM, Christian Borntraeger wrote:
On 12/06/12 13:57, Alexander Graf wrote:
Since it lives in an s390 specific branch, the function name should probably be
called s390 specific. If we ever n
On 2012-06-12 14:12, Alexander Graf wrote:
> On 06/12/2012 02:02 PM, Christian Borntraeger wrote:
>> On 12/06/12 13:57, Alexander Graf wrote:
>>> Since it lives in an s390 specific branch, the function name should
>>> probably be called s390 specific. If we ever need another architecture to
>>> h
On 06/12/2012 02:02 PM, Christian Borntraeger wrote:
On 12/06/12 13:57, Alexander Graf wrote:
Since it lives in an s390 specific branch, the function name should probably be
called s390 specific. If we ever need another architecture to have a kvm
specific ram allocator, we can make it generic
On 12/06/12 13:57, Alexander Graf wrote:
> Since it lives in an s390 specific branch, the function name should probably
> be called s390 specific. If we ever need another architecture to have a kvm
> specific ram allocator, we can make it generic when that time comes. Until
> then, let's treat s
On 06/12/2012 01:20 PM, Christian Borntraeger wrote:
Is there any way we can move the above code to target-s390x? Having the
branch below is already invasive enough for generic code, but we really
don't need all the special s390 quirks to live here.
Hmm, we have to have a special hook somehow.
> Is there any way we can move the above code to target-s390x? Having the
> branch below is already invasive enough for generic code, but we really
> don't need all the special s390 quirks to live here.
Hmm, we have to have a special hook somehow.
What about this approach?
--
Jens Freimann wrote:
> From: Christian Borntraeger
>
> By default qemu will use MAP_PRIVATE for guest pages. This will write
> protect pages and thus break on s390 systems that dont support this feature.
> Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
> has other prob
From: Christian Borntraeger
By default qemu will use MAP_PRIVATE for guest pages. This will write
protect pages and thus break on s390 systems that dont support this feature.
Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
has other problems (no dirty pages tracking, a
13 matches
Mail list logo
