On Wed, Feb 20, 2008 at 04:25:42PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
+ /*
+ * Largepage creation is susceptible to a upper-level
+ * table to be shadowed and write-protected in the
+ * area being mapped.
Marcelo Tosatti wrote:
I don't follow. Can you describe the scenario in more detail? The state
of the guest and shadow page tables, and what actually happens?
Have a kernel level-3 table at guest physical address 0x280.
The kernel direct translation which maps to that
Marcelo Tosatti wrote:
+ /*
+* Largepage creation is susceptible to a upper-level
+* table to be shadowed and write-protected in the
+* area being mapped. If that is the case, invalidate
+*
On Sun, Feb 17, 2008 at 11:38:51AM +0200, Avi Kivity wrote:
+ * Return the pointer to the largepage write count for a given
+ * gfn, handling slots that are not large page aligned.
+ */
+static int *slot_largepage_idx(gfn_t gfn, struct kvm_memory_slot *slot)
+{
+unsigned long idx;
+
+
Marcelo Tosatti wrote:
On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
gfn_to_page() needs to grab the struct page corresponding to the large
page, not the offset struct page for the faulting 4k address within
the large frame. Since gfn_to_page can sleep, there is no way to do
On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
gfn_to_page() needs to grab the struct page corresponding to the large
page, not the offset struct page for the faulting 4k address within
the large frame. Since gfn_to_page can sleep, there is no way to do
that in the mapping logic
On Fri, Feb 15, 2008 at 12:17:39AM +0100, Marcelo Tosatti wrote:
On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
gfn_to_page() needs to grab the struct page corresponding to the large
page, not the offset struct page for the faulting 4k address within
the large frame. Since
On Tue, Feb 12, 2008 at 01:55:54PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Ok, how does the following look. Still need to plug in large page
creation in the nonpaging case, but this should be enough for comments.
Most of the comments are cosmetic, but a couple have some meat.
Marcelo Tosatti wrote:
+ /*
+* If its a largepage mapping, there could be a previous
+* pointer to a PTE page hanging there, which will falsely
+* set was_rmapped.
+*/
+ if (largepage)
+ was_rmapped = is_large_pte(*shadow_pte);
+
But that pte page
Marcelo Tosatti wrote:
Ok, how does the following look. Still need to plug in large page
creation in the nonpaging case, but this should be enough for comments.
Most of the comments are cosmetic, but a couple have some meat.
+#define HPAGE_ALIGN_OFFSET(x)
On Thu, Jan 31, 2008 at 07:44:52AM +0200, Avi Kivity wrote:
Joerg Roedel wrote:
On Tue, Jan 29, 2008 at 07:20:12PM +0200, Avi Kivity wrote:
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included
On Tue, Jan 29, 2008 at 07:20:12PM +0200, Avi Kivity wrote:
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included within that memory slot. Each entry in
the array contains the number of write-protected
Joerg Roedel wrote:
On Tue, Jan 29, 2008 at 07:20:12PM +0200, Avi Kivity wrote:
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included within that memory slot. Each entry in
the array contains the
The npt patches started me thinking on large page support (2MB/4MB
pages), and I think we can implement them even when npt/ept are not
available.
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included within
14 matches
Mail list logo
