On Thu, 2011-08-25 at 08:08 -0700, David Evensky wrote:
> Adding in the rest of what ivshmem does shouldn't affect our use, *I
> think*. I hadn't intended this to do everything that ivshmem does,
> but I can see how that would be useful. It would be cool if it could
> grow into that.
David,
I'v
On Thu, 2011-08-25 at 16:25 +, Decker, Schorschi wrote:
> I would ask two things be done in the design if it goes forward, 1)
> have an explicit way to disable this feature, where the hypervisor
> cannot interact with the guest OS directly in any way if disablement
> is selected.
I doubt that
On Thu, 2011-08-25 at 16:35 -0500, Anthony Liguori wrote:
> On 08/24/2011 05:25 PM, David Evensky wrote:
> >
> >
> > This patch adds a PCI device that provides PCI device memory to the
> > guest. This memory in the guest exists as a shared memory segment in
> > the host. This is similar memory shar
On Thu, 2011-08-25 at 16:48 -0500, Anthony Liguori wrote:
> On 08/25/2011 12:21 AM, Sasha Levin wrote:
> > Hi,
> >
> > Currently when we run the guest we treat it as a black box, we're not
> > quite sure what it's going to start and whether it supports the same
> > features we expect it to support
hi,Avi:
I met the same problem, tons of hpet vm_exits(vector 209, fault
address is in the guest vm's hpet mmio range), even I disable hpet
device in win7 guest vm, it still produce a larget amount of vm_exits
when trace-cmd ; I add -no-hpet to start the vm, it still has HPET
device inside VM.
On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
>
> On 25.08.2011, at 07:31, Roedel, Joerg wrote:
>
> > On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> >> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> >
>
> [...]
>
> >> We need to try the polite m
On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
>
> > > I don't see a reason to make this meta-grouping static. It would harm
> > > flexibility on x86.
On 08/25/2011 09:47 PM, Marcelo Tosatti wrote:
> I guess it is OK to be more trigger happy with zapping by ignoring
> the accessed bit, clearing the flood counter on page fault.
>
Yeah, i like this way, is this patch good for you?
Subject: [PATCH 11/11] KVM: MMU
On 08/22/2011 10:41 AM, Avi Kivity wrote:
As it is exposed directly to guest code, the x86 emulator is an interesting
target for exploiters: a vulnerability may lead to compromise of the entire
host.
In an attempt to catch vulnerabilities before they make it into production
code, this patchset a
On Wed, Aug 24, 2011 at 1:25 AM, pradeep wrote:
> On Wed, 24 Aug 2011 01:05:13 -0300
> Lucas Meneghel Rodrigues wrote:
>
>> Tests the ability of adding virtual cpus on the fly to qemu using
>> the monitor command cpu_set, then after everything is OK, run the
>> cpu_hotplug testsuite on the guest
Tests the ability of adding virtual cpus on the fly to qemu using
the monitor command cpu_set, then after everything is OK, run the
cpu_hotplug testsuite on the guest through autotest.
Updates: As of the latest qemu-kvm (08-24-2011) HEAD, trying to
online more CPUs than the ones already available
Thanks. My initial version did use the E820 map (thus the reason I
want to have an 'address family'), but it was suggested that PCI would
be a better way to go. When I get the rest of the project going, I
will certainly test against that. I am going to have to do a LOT of
ioremap's so that might
On 08/22/2011 10:41 AM, Avi Kivity wrote:
The x86 emulator is directly exposed to guest code; therefore it is part
of the directly exposed attack surface. To reduce the risk of
vulnerabilities, this patch adds a fuzz test that runs random instructions
through the emulator. A vulnerability will
Just FYI, one issue that I found with exposing host memory regions as
a PCI BAR (including via a very old version of the ivshmem driver...
haven't tried a newer one) is that x86's pci_mmap_page_range doesn't
want to set up a write-back cacheable mapping of a BAR.
It may not matter for your require
I need to specify the physical address because I need to ioremap the
memory during boot.
The production issue I think is a memory limitation. We certainly do
use QEMU a lot; but for this the kvm tool is a better fit.
\dae
On Fri, Aug 26, 2011 at 12:11:03AM +0300, Avi Kivity wrote:
> On 08/26/20
On Thu, Aug 25, 2011 at 04:35:29PM -0500, Anthony Liguori wrote:
dev.h
>
> >--- linux-kvm/tools/kvm/include/kvm/virtio-pci-dev.h 2011-08-09
> >15:38:48.760120973 -0700
> >+++ linux-kvm_pci_shmem/tools/kvm/include/kvm/virtio-pci-dev.h
> >2011-08-18 10:06:12.171539230 -0700
> >@@ -15,10
On 08/25/2011 12:21 AM, Sasha Levin wrote:
Hi,
Currently when we run the guest we treat it as a black box, we're not
quite sure what it's going to start and whether it supports the same
features we expect it to support when running it from the host.
This forces us to start the guest with the sa
On 08/24/2011 05:25 PM, David Evensky wrote:
This patch adds a PCI device that provides PCI device memory to the
guest. This memory in the guest exists as a shared memory segment in
the host. This is similar memory sharing capability of Nahanni
(ivshmem) available in QEMU. In this case, the sha
On 08/26/2011 12:00 AM, David Evensky wrote:
I've tested ivshmem with the latest git pull (had minor trouble
building on debian sid, vnc and unused var, but trivial to work
around).
QEMU's -device ivshmem,size=16,shm=/kvm_shmem
seems to function as my proposed
--shmem pci:0xfd00:
I've tested ivshmem with the latest git pull (had minor trouble
building on debian sid, vnc and unused var, but trivial to work
around).
QEMU's -device ivshmem,size=16,shm=/kvm_shmem
seems to function as my proposed
--shmem pci:0xfd00:16M:handle=/kvm_shmem
except that I can't spec
On 08/22/2011 10:41 AM, Avi Kivity wrote:
As it is exposed directly to guest code, the x86 emulator is an interesting
target for exploiters: a vulnerability may lead to compromise of the entire
host.
In an attempt to catch vulnerabilities before they make it into production
code, this patchset a
On 08/25/2011 07:27 PM, Marcelo Tosatti wrote:
On Mon, Aug 22, 2011 at 04:41:09PM +0300, Avi Kivity wrote:
> The x86 emulator is directly exposed to guest code; therefore it is part
> of the directly exposed attack surface. To reduce the risk of
> vulnerabilities, this patch adds a fuzz test
On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iomm
On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> Hi Alex,
>
> On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> > Is this roughly what you're thinking of for the iommu_group component?
> > Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> > support
On Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote:
> On 08/25/2011 06:54 AM, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iommu-ops per-bus.
>
>From a security perspective, this not a great idea. Security isolation in
>virtualization is gaining ground, so anything that breaches the
>hypervisor/guest vale is by your typical enterprise/company security team
>considered completely illegal, a number of firms I have talked with all are
>t
On Mon, Aug 22, 2011 at 04:41:09PM +0300, Avi Kivity wrote:
> The x86 emulator is directly exposed to guest code; therefore it is part
> of the directly exposed attack surface. To reduce the risk of
> vulnerabilities, this patch adds a fuzz test that runs random instructions
> through the emulator
On 08/25/2011 06:54 AM, Roedel, Joerg wrote:
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would
Adding in the rest of what ivshmem does shouldn't affect our use, *I
think*. I hadn't intended this to do everything that ivshmem does,
but I can see how that would be useful. It would be cool if it could
grow into that.
Our requirements for the driver in kvm tool are that another program
on the
On 25.08.2011, at 04:30, Aashish Mittal wrote:
>
> On Thu, Aug 25, 2011 at 4:04 AM, Alexander Graf wrote:
>
> On 19.08.2011, at 06:45, Aashish Mittal wrote:
>
> > Hi
> > I'm trying to emulate the lwzu instruction in e500 powerpc kvm for my
> > project .
> > I've removed the read and write pr
On Thu, 2011-08-25 at 17:40 +0300, Avi Kivity wrote:
> On 08/25/2011 05:39 PM, Sasha Levin wrote:
> > On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote:
> > > On 08/25/2011 04:29 PM, Sasha Levin wrote:
> > > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest
> > > > wants
On 08/25/2011 05:39 PM, Sasha Levin wrote:
On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote:
> On 08/25/2011 04:29 PM, Sasha Levin wrote:
> > 2. The spec describes DOORBELL as an array of DWORDs, when one guest
> > wants to poke a different guest it would write something into the offset
>
We have 3 privilege levels: problem state, supervisor state and hypervisor
state. Each of them can access different SPRs, so we need to check on every
SPR if it's accessible in the respective mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_emulate.c | 25 +++
When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV mode, but it ended up being a lot easier this w
We need the compute_tlbie_rb in _pr and _hv implementations for papr
soon, so let's move it over to a common header file that both
implementations can leverage.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h | 33 +
arch/powerpc/kvm/book
We have a few traps where we cache the instruction that cause the trap
for analysis later on. Since we now need to be able to distinguish
between SC 0 and SC 1 system calls and the only way to find out which
is which is by looking at the instruction, we also read out the instruction
causing the sys
From: Paul Mackerras
With a KVM guest operating in SMT4 mode (i.e. 4 hardware threads per
core), whenever a CPU goes idle, we have to pull all the other
hardware threads in the core out of the guest, because the H_CEDE
hcall is handled in the kernel. This is inefficient.
This adds code to book3
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/powerpc.c |5 +
include/linux/kvm.h|1 +
2 files changed, 6 insertio
From: Paul Mackerras
This makes arch/powerpc/kvm/book3s_rmhandlers.S and
arch/powerpc/kvm/book3s_hv_rmhandlers.S be assembled as
separate compilation units rather than having them #included in
arch/powerpc/kernel/exceptions-64s.S. We no longer have any
conditional branches between the exception
There are multiple features in PowerPC KVM that can now be enabled
depending on the user's wishes. Some of the combinations don't make
sense or don't work though.
So this patch adds a way to check if the executing environment would
actually be able to run the guest properly. It also adds sanity
ch
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.
We keep the old PVR based way around for backwards compatibility, but
once user space uses th
Recent Linux versions use the CFAR and PURR SPRs, but don't really care about
their contents (yet). So for now, we can simply return 0 when the guest wants
to read them.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_emulate.c |4
1 files changed, 4 insertions(+), 0 deletions
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
page tables and does other privileged operations that it wouldn't be allowed
to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them
through the same PAPR hypercall interface
From: Paul Mackerras
This simplifies the way that the book3s_pr makes the transition to
real mode when entering the guest. We now call kvmppc_entry_trampoline
(renamed from kvmppc_rmcall) in the base kernel using a normal function
call instead of doing an indirect call through a pointer in the v
When running a PAPR guest, the guest is not allowed to set SDR1 - instead
the HTAB information is held in internal hypervisor structures. But all of
our current code relies on SDR1 and walking the HTAB like on real hardware.
So in order to not be too intrusive, we simply set SDR1 to the HTAB we ho
Hi Avi,
This is my current patch queue for ppc. Please pull.
Alex
The following changes since commit ef7c782ea4a99fafb3d60dc8b8c057e0ef14f9f7:
Nadav Har'El (1):
KVM: SVM: Fix TSC MSR read in nested SVM
are available in the git repository at:
git://github.com/agraf/linux-2.6.git kv
When running a PAPR guest, some things change. The privilege level drops
from hypervisor to supervisor, SDR1 gets treated differently and we interpret
hypercalls. For bisectability sake, add the flag now, but only enable it when
all the support code is there.
Signed-off-by: Alexander Graf
---
ar
On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote:
> On 08/25/2011 04:29 PM, Sasha Levin wrote:
> > 2. The spec describes DOORBELL as an array of DWORDs, when one guest
> > wants to poke a different guest it would write something into the offset
> > of the other guest in the DOORBELL array.
> > L
On 08/25/2011 04:21 PM, Marcelo Tosatti wrote:
On Thu, Aug 25, 2011 at 07:42:10AM +0300, Avi Kivity wrote:
> On 08/25/2011 05:04 AM, Marcelo Tosatti wrote:
> >>
> >> It could increase the flood count independently of the accessed bit of
> >> the spte being updated, zapping after 3 attempt
On 08/25/2011 05:06 PM, Avi Kivity wrote:
On 08/25/2011 04:21 PM, Marcelo Tosatti wrote:
On Thu, Aug 25, 2011 at 07:42:10AM +0300, Avi Kivity wrote:
> On 08/25/2011 05:04 AM, Marcelo Tosatti wrote:
> >>
> >> It could increase the flood count independently of the
accessed bit of
> >> the s
On 08/25/2011 04:29 PM, Sasha Levin wrote:
2. The spec describes DOORBELL as an array of DWORDs, when one guest
wants to poke a different guest it would write something into the offset
of the other guest in the DOORBELL array.
Looking at the implementation in QEMU, DOORBELL is one DWORD, when
wri
On Thu, Aug 25, 2011 at 07:42:10AM +0300, Avi Kivity wrote:
> On 08/25/2011 05:04 AM, Marcelo Tosatti wrote:
> >>
> >> It could increase the flood count independently of the accessed bit of
> >> the spte being updated, zapping after 3 attempts as it is now.
> >>
> >> But additionally reset the f
On Thu, Aug 25, 2011 at 03:57:22PM +0800, Xiao Guangrong wrote:
> On 08/24/2011 03:09 AM, Marcelo Tosatti wrote:
> > On Wed, Aug 24, 2011 at 12:32:32AM +0800, Xiao Guangrong wrote:
> >> On 08/23/2011 08:38 PM, Marcelo Tosatti wrote:
> >>
> And, i think there are not problems since: if the spte
Hello,
I am looking to implement an ivshmem device for KVM tools, the purpose
is to provide same functionality as QEMU and interoperability with QEMU.
Going through the spec (I found here:
https://gitorious.org/nahanni/guest-code/blobs/master/device_spec.txt )
and the code in QEMU I have gathered
On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> > On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
> > > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> >
> > > > Handling it through fds is a goo
On 08/25/2011 02:38 PM, Pekka Enberg wrote:
>> If you or other KVM folks want to have a say what goes into tools/kvm,
>> I'm happy to send you a pull request against kvm.git.
On Thu, Aug 25, 2011 at 2:51 PM, Avi Kivity wrote:
> Thanks, but I have my hands full already. I'll stop offering unwante
On 08/25/2011 02:38 PM, Pekka Enberg wrote:
If you or other KVM folks want to have a say what goes into tools/kvm,
I'm happy to send you a pull request against kvm.git.
Thanks, but I have my hands full already. I'll stop offering unwanted
advice as well.
Anyway, Sasha thinks ivshmem is the
On Thu, 2011-08-25 at 14:30 +0300, Avi Kivity wrote:
> On 08/25/2011 02:15 PM, Pekka Enberg wrote:
> > On Thu, Aug 25, 2011 at 1:59 PM, Stefan Hajnoczi wrote:
> > > Introducing yet another non-standard and non-Linux interface doesn't
> > > help though. If there is no significant improvement ove
On Thu, Aug 25, 2011 at 2:30 PM, Avi Kivity wrote:
> On 08/25/2011 02:15 PM, Pekka Enberg wrote:
>>
>> On Thu, Aug 25, 2011 at 1:59 PM, Stefan Hajnoczi
>> wrote:
>> > Introducing yet another non-standard and non-Linux interface doesn't
>> > help though. If there is no significant improvement o
On 08/25/2011 02:15 PM, Pekka Enberg wrote:
On Thu, Aug 25, 2011 at 1:59 PM, Stefan Hajnoczi wrote:
> Introducing yet another non-standard and non-Linux interface doesn't
> help though. If there is no significant improvement over ivshmem then
> it makes sense to let ivshmem gain critical mas
On Thu, 2011-08-25 at 11:59 +0100, Stefan Hajnoczi wrote:
> On Thu, Aug 25, 2011 at 11:37 AM, Pekka Enberg wrote:
> > Hi Stefan,
> >
> > On Thu, Aug 25, 2011 at 1:31 PM, Stefan Hajnoczi wrote:
> >>> It's obviously not competing. One thing you might want to consider is
> >>> making the guest inter
On Thu, Aug 25, 2011 at 1:59 PM, Stefan Hajnoczi wrote:
> Introducing yet another non-standard and non-Linux interface doesn't
> help though. If there is no significant improvement over ivshmem then
> it makes sense to let ivshmem gain critical mass and more users
> instead of fragmenting the spa
On Thu, Aug 25, 2011 at 11:54:41AM +0100, Stefan Hajnoczi wrote:
> On Mon, Jul 4, 2011 at 11:00 PM, Raghavendra D Prabhu
> wrote:
> > The gnutls_*_set_priority family of functions has been marked deprecated
> > in 2.12.x. These functions have been superceded by
> > gnutls_priority_set_direct().
>
On Wed, Aug 24, 2011 at 10:56:13AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
> > A side-note: Might it be better to expose assigned devices in a guest on
> > a seperate bus? This will make it easier to emulate an IOMMU for the
> > guest inside qemu.
>
>
On Thu, Aug 25, 2011 at 11:37 AM, Pekka Enberg wrote:
> Hi Stefan,
>
> On Thu, Aug 25, 2011 at 1:31 PM, Stefan Hajnoczi wrote:
>>> It's obviously not competing. One thing you might want to consider is
>>> making the guest interface compatible with ivshmem. Is there any reason
>>> we shouldn't do
On Mon, Jul 4, 2011 at 11:00 PM, Raghavendra D Prabhu
wrote:
> The gnutls_*_set_priority family of functions has been marked deprecated
> in 2.12.x. These functions have been superceded by
> gnutls_priority_set_direct().
>
> Signed-off-by: Raghavendra D Prabhu
> ---
> ui/vnc-tls.c | 20 +--
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> Is this roughly what you're thinking of for the iommu_group component?
> Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> support in the iommu base. Would AMD-Vi do something similar (or
> exactly
Hi Stefan,
On Thu, Aug 25, 2011 at 1:31 PM, Stefan Hajnoczi wrote:
>> It's obviously not competing. One thing you might want to consider is
>> making the guest interface compatible with ivshmem. Is there any reason
>> we shouldn't do that? I don't consider that a requirement, just nice to
>> have
On Thu, Aug 25, 2011 at 6:06 AM, Pekka Enberg wrote:
> On Wed, 2011-08-24 at 21:49 -0700, David Evensky wrote:
>> On Wed, Aug 24, 2011 at 10:27:18PM -0500, Alexander Graf wrote:
>> >
>> > On 24.08.2011, at 17:25, David Evensky wrote:
>> >
>> > >
>> > >
>> > > This patch adds a PCI device that prov
On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> > From what I gathered libguestfs only provides access to the guests'
> > image.
>
> Correct.
>
> > Which part is doing the IKCONFIG or System.map probing? Or is it
On 08/24/2011 03:09 AM, Marcelo Tosatti wrote:
> On Wed, Aug 24, 2011 at 12:32:32AM +0800, Xiao Guangrong wrote:
>> On 08/23/2011 08:38 PM, Marcelo Tosatti wrote:
>>
And, i think there are not problems since: if the spte without accssed bit
is
written frequently, it means the guest
On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> From what I gathered libguestfs only provides access to the guests'
> image.
Correct.
> Which part is doing the IKCONFIG or System.map probing? Or is it done in
> a different way?
You'll have to see what Matt's doing in the virt-v2v
On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> > On 08/25/2011 08:21 AM, Sasha Levin wrote:
> > >Hi,
> > >
> > >Currently when we run the guest we treat it as a black box, we're not
> > >quite sure what it's going to star
On 08/25/2011 10:04 AM, Marcelo Tosatti wrote:
>>> Yes, in this case, the sp is not zapped, but it is hardly to know the gfn
>>> is not used as gpte just depends on writing, for example, the guest can
>>> change the mapping address or the status bit, and so on...The sp can be
>>> zapped if the gue
On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> On 08/25/2011 08:21 AM, Sasha Levin wrote:
> >Hi,
> >
> >Currently when we run the guest we treat it as a black box, we're not
> >quite sure what it's going to start and whether it supports the same
> >features we expect it to support wh
On 8/25/11 10:20 AM, Asias He wrote:
On Thu, Aug 25, 2011 at 3:02 PM, Pekka Enberg wrote:
On 8/25/11 9:30 AM, Asias He wrote:
On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enbergwrote:
On 8/25/11 8:34 AM, Asias He wrote:
Hi, David
On Thu, Aug 25, 2011 at 6:25 AM, David Evensky
wrote:
This p
On Thu, Aug 25, 2011 at 3:02 PM, Pekka Enberg wrote:
> On 8/25/11 9:30 AM, Asias He wrote:
>>
>> On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg wrote:
>>>
>>> On 8/25/11 8:34 AM, Asias He wrote:
>>>
>>> Hi, David
>>>
>>> On Thu, Aug 25, 2011 at 6:25 AM, David Evensky
>>> wrote:
This pat
On 8/25/11 9:30 AM, Asias He wrote:
On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg wrote:
On 8/25/11 8:34 AM, Asias He wrote:
Hi, David
On Thu, Aug 25, 2011 at 6:25 AM, David Evensky wrote:
This patch adds a PCI device that provides PCI device memory to the
guest. This memory in the guest e
79 matches
Mail list logo
