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
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> lat_ctx -s 0 [zero memory footprint]:
>>>
>>> -
>>>#tasksnativekvm-r4204kvm-r4232(mmu)
>>> -
>>>
Anthony Liguori wrote:
>
> This should be hookable via arch_{enter,leave}_cpu_mode() via
> paravirt_ops. I was actually just looking at this myself (although I
> was focusing on lazy mmu hooks). I've taken the route of using a VMI
> ROM to actually hook it (instead of implementing a custom par
Parag Warudkar wrote:
>>> After letting it run for some time qemu aborted abruptly
>>> with this on console -
>>>
>>> unhandled vm exit: 0x9
>>> rax fec1fc08 rbx 09db01b0
>>> rcx 09db019c rdx 09db
>>> rsi 09db01b0 rdi 0014
>>> rsp
digital tech support wrote:
> Do we want screenshots of kvm running guests?
Yes we do. I've already got some, but haven't had time to post them. I
plan to wikify the site so people can add screenshots themselves.
--
error compiling committee.c: too many arguments to function
--
Michael Riepe wrote:
> Hi!
>
> Avi Kivity wrote:
>
>
>>> on a related note, i also got:
>>>
>>> vmwrite error: reg 6802 value cfd3c4a4 (err 17408)
>>>
>> This is already fixed on the trunk (which now has mmu merged).
>>
>
> Actually not. Now it reads:
>
> vmwrite error: reg 680
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >actually, the VM entry+exit cost on this CPU is around 3-4
> >microseconds, so it's still 2 VM exits per context switch.
> >
> >I debugged this a bit, and what happens is that when Linux does a
> >task-switch it does a cr3 load /and/ a write (look at _
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> actually, the VM entry+exit cost on this CPU is around 3-4
>>> microseconds, so it's still 2 VM exits per context switch.
>>>
>>> I debugged this a bit, and what happens is that when Linux does a
>>> task-switch it does a cr3
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> A question. What's __flush_tlb() doing in the context switch path?
> Shouldn't it just load the new cr3 and be done with it?
hmm it /does/ use load_cr3, which uses write_cr3(). Maybe i'm wrong
about this analysis and the 'speedup' was a cache ali
* 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:
> * 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 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
* 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
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:
> 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
* 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)
> >
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
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
* 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.
* 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
* 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
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 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:
> * 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
* 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:
> * 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
* 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 <[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
Hello,
This patch adds a kvm_save_registers call before each command run in
qemu monitor. This affects commands such as "info registers," "info
tlb," and "info mem."
This is to synchronize the cpu state so that monitor commands are more
accurate.
Best Regards,
David Beal
Index: trunk/qemu/monit
Avi Kivity <[EMAIL PROTECTED]> writes:
> 32-bin kvm userspace can run a 64-bit guest, if you're using a 64-bit os
> kernel, hence the 64-bit registers. Just ignore the 64-bit parts.
>
Didn't understand. Allow me to clarify a bit -
I am running a 32-bit Host OS (Linux i386) on a purely 32-bit
As I mentioned in a previous note, I've been playing around with using
VMI to paravirtualize KVM. There are a couple of interesting things
about this that I thought I'd share what I currently have.
Unlike lhype or Xen, VMI simply redirects most sensitive operations into
a block of code that's
31 matches
Mail list logo
