* Avi Kivity <[EMAIL PROTECTED]> wrote:
> The guest needs to cooperate, but it can do so using the native memory
> hotlpug mechanisms (whatever they are). [...]
as far a Linux guest goes, there's no such thing at the moment, at least
in the mainline kernel. Most of the difficulties with RAM-un
Ingo Molnar wrote:
> another small detail is that currently KVM_SET_MEMORY_REGION appears to
> be an add-only interface - it is not possible to 'unregister' RAM from a
> VM.
>
Well, the _interface_ supports removing, the implementation does not :)
Everything was written in mind to allow memo
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>> ok. How about the patch below then? This only addresses the OOM
>> scenario, not the !memslot case.
>>
>
> the !memslot case is covered by the patch below. Injecting a #GPF is the
> easiest one to do here, although we co
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> instead of a host crash. Note that i chose to put this into the
> generic cr3 loading function, so that it covers real-mode too. I think
> we can safely ignore a BIOS loading crap into cr3 and after that
> loading the right value into it. (if that eve
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok. How about the patch below then? This only addresses the OOM
> scenario, not the !memslot case.
the !memslot case is covered by the patch below. Injecting a #GPF is the
easiest one to do here, although we could do a triple fault too - i just
dont
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>> Yes.
>>
>> A read-only memory slot may have other uses too (for ROMs).
>>
>
> a related question: i was wondering about the purpose of the
> KVM_MEM_LOG_DIRTY_PAGES feature that is attached to physical memory
> slots. Is
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Yes.
>
> A read-only memory slot may have other uses too (for ROMs).
a related question: i was wondering about the purpose of the
KVM_MEM_LOG_DIRTY_PAGES feature that is attached to physical memory
slots. Is that used so that you can get a compact bit
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>>> The kvm goals do not include cycle accurate emulation. [...]
>>>
>> yes. That's why i'm suggesting to kill the VM in such a scenario. A
>> cr3 value is only valid if it points to real RAM.
>>
>
> and if it ever ca
Ingo Molnar wrote:
> ok. How about the patch below then? This only addresses the OOM
> scenario, not the !memslot case.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
Take Surveys
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>> Note that the corner cases will never be 100% emulatable. For
>> example, you can set cr3 to point at your IDE DMA mmio space or
>> something like that. It's quite all right to kill the guest quietly
>> at that point, as no
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > The kvm goals do not include cycle accurate emulation. [...]
>
> yes. That's why i'm suggesting to kill the VM in such a scenario. A
> cr3 value is only valid if it points to real RAM.
and if it ever causes real incompatibility it should be easy to
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Right not the list is not LRU, so a zap can kill your parent page
> table. I'm also worried about preserving invariants, as the page
> tables are linked through a variety of data structures. Calling
> zap_page() while another operation is in progress
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Note that the corner cases will never be 100% emulatable. For
> example, you can set cr3 to point at your IDE DMA mmio space or
> something like that. It's quite all right to kill the guest quietly
> at that point, as no real-life guest will do that.
Ingo Molnar wrote:
>
>> The context switch paths need to do the same.
>>
>
> yeah. Although, as this example has shown it, such implicit assumptions
> carried into code tends to be volatile. Couldnt the kvm_mmu_zap_page()
> be done implicitly within kvm_mmu_alloc_page()? As long as the li
Ingo Molnar wrote:
>> That's a good solution. I don't see why it has to be made
>> non-writable -- it has undefined content, and any old value will do.
>> We have (or maybe had) something like that somewhere.
>>
>
> it should always return 0xff content because that's how real hardware
> b
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >hm, where do we ensure that? kvm_mmu_get_page() calls
> >kvm_mmu_alloc_page(), which might return NULL:
> >
> > static struct kvm_mmu_page *kvm_mmu_alloc_page(struct kvm_vcpu *vcpu,
> >u64 *parent_pte)
> >
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>rmap_write_protect() has a BUG_ON() if a physical address is not
> >>>found the the memslot. But this is a possible scenario if a buggy
> >>>guest OS loads an invalid or corrup
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> [ Avi: this patch needs kvm_mmu_get_page() NULL return to not be ignored
>>> by mmu_alloc_roots()/nonpaging_init_context()/paging_new_cr3()/etc.
>>> and passed further down - i assume you are working on those
>>> issues al
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >[ Avi: this patch needs kvm_mmu_get_page() NULL return to not be ignored
> > by mmu_alloc_roots()/nonpaging_init_context()/paging_new_cr3()/etc.
> > and passed further down - i assume you are working on those
> > issues already, or should i fix thos
Avi Kivity wrote:
> Ingo Molnar wrote:
>> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>>
>>
rmap_write_protect() has a BUG_ON() if a physical address is not
found the the memslot. But this is a possible scenario if a buggy
guest OS loads an invalid or corrupted cr3 value. So exit mor
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> rmap_write_protect() has a BUG_ON() if a physical address is not
>>> found the the memslot. But this is a possible scenario if a buggy
>>> guest OS loads an invalid or corrupted cr3 value. So exit more
>>> gracefully.
>>>
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >rmap_write_protect() has a BUG_ON() if a physical address is not
> >found the the memslot. But this is a possible scenario if a buggy
> >guest OS loads an invalid or corrupted cr3 value. So exit more
> >gracefully.
>
> I think a better solution is to
Ingo Molnar wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Subject: [patch] kvm: make cr3 loading more robust
>
> rmap_write_protect() has a BUG_ON() if a physical address is not found
> the the memslot. But this is a possible scenario if a buggy guest OS
> loads an invalid or corrupted cr3 val
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: [patch] kvm: make cr3 loading more robust
rmap_write_protect() has a BUG_ON() if a physical address is not found
the the memslot. But this is a possible scenario if a buggy guest OS
loads an invalid or corrupted cr3 value. So exit more gracefully.
24 matches
Mail list logo
