On Tue, Mar 9, 2010 at 5:03 PM, Paul Brook p...@codesourcery.com wrote:
In a cross environment that becomes extremely hairy. For example the x86
architecture effectively has an implicit write barrier before every
store, and an implicit read barrier before every load.
Btw, x86 doesn't have
Hello,
I was wondering if someone could point me to some documentation that
explains the basic non-nested-paging shadow page table
algorithm/strategy used by KVM. I understand that KVM caches shadow
page tables across context switches and that there is a reverse mapping
and page protection
-Original Message-
From: Gleb Natapov [mailto:g...@redhat.com]
Sent: Friday, January 22, 2010 00:58
To: Jimmy Crossley
Cc: 'Jim Paris'; 'kvm@vger.kernel.org'
Subject: Re: Some keys don't repeat in 64 bit Widows 7 kvm guest
On Thu, Jan 21, 2010 at 05:35:08PM -0600, Jimmy Crossley
http://aneqedom.maddsites.com/uqyvewox.html
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09.03.2010, at 07:13, Wei Yongjun wrote:
If fail to create the vcpu, we should not create the debugfs
for it.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Good catch.
I guess a goto out kind of construct would be better, but for a single line of
code this is enough. And whoever
On 03/09/2010 03:01 PM, Alexander Graf wrote:
On 09.03.2010, at 13:56, Avi Kivity wrote:
On 03/08/2010 08:03 PM, Alexander Graf wrote:
Some times we don't want all capabilities to be available to all
our vcpus. One example for that is the OSI interface, implemented
in the next
On 09.03.2010, at 14:11, Avi Kivity wrote:
On 03/09/2010 03:04 PM, Alexander Graf wrote:
+ /* KVM_EXIT_OSI */
+ struct {
+ __u64 gprs[32];
+ } osi;
+
+MOL uses a special hypercall interface it calls 'OSI'. To enable it, we
catch
+hypercalls
On 03/09/2010 03:04 PM, Alexander Graf wrote:
+ /* KVM_EXIT_OSI */
+ struct {
+ __u64 gprs[32];
+ } osi;
+
+MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
+hypercalls and exit with this exit struct
On 09.03.2010, at 14:19, Avi Kivity wrote:
On 03/09/2010 03:12 PM, Alexander Graf wrote:
On 09.03.2010, at 14:11, Avi Kivity wrote:
On 03/09/2010 03:04 PM, Alexander Graf wrote:
+/* KVM_EXIT_OSI */
+struct {
+__u64
On 03/09/2010 03:12 PM, Alexander Graf wrote:
On 09.03.2010, at 14:11, Avi Kivity wrote:
On 03/09/2010 03:04 PM, Alexander Graf wrote:
+ /* KVM_EXIT_OSI */
+ struct {
+ __u64 gprs[32];
+ } osi;
+
+MOL uses a
On 03/08/2010 08:03 PM, Alexander Graf wrote:
Userspace can tell us that it wants to trigger an interrupt. But
so far it can't tell us that it wants to stop triggering one.
So let's interpret the parameter to the ioctl that we have anyways
to tell us if we want to raise or lower the interrupt
On 03/08/2010 08:03 PM, Alexander Graf wrote:
Some times we don't want all capabilities to be available to all
our vcpus. One example for that is the OSI interface, implemented
in the next patch.
In order to have a generic mechanism in how to enable capabilities
individually, this patch
On 03/09/2010 02:54 PM, Alexander Graf wrote:
On 09.03.2010, at 13:50, Avi Kivity wrote:
On 03/08/2010 08:03 PM, Alexander Graf wrote:
Userspace can tell us that it wants to trigger an interrupt. But
so far it can't tell us that it wants to stop triggering one.
So let's interpret
101 - 113 of 113 matches
Mail list logo
