On 8/25/11 10:20 AM, Asias He wrote:
On Thu, Aug 25, 2011 at 3:02 PM, Pekka Enberg<penberg@xxxxxxxxxx> wrote:
On 8/25/11 9:30 AM, Asias He wrote:
On Thu, Aug 25, 2011 at 1:54 PM, Pekka Enberg<penberg@xxxxxxxxxx> wrote:
On 8/25/11 8:34 AM, Asias He wrote:
Hi, David
On Thu, Aug 25, 2011 at 6:25 AM, David Evensky<evensky@xxxxxxxxxx>
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 shared memory segment
is exposed as a PCI BAR only.
A new command line argument is added as:
--shmem pci:0xc8000000:16MB:handle=/newmem:create
which will set the PCI BAR at 0xc8000000, the shared memory segment
and the region pointed to by the BAR will be 16MB. On the host side
the shm_open handle will be '/newmem', and the kvm tool will create
the shared segment, set its size, and initialize it. If the size,
handle, or create flag are absent, they will default to 16MB,
handle=/kvm_shmem, and create will be false.
I think it's better to use a default BAR address if user does not specify
one as well.
This way,
./kvm --shmem
will work with default values with zero configuration.
Does that sort of thing make sense here? It's a special purpose device
and the guest is expected to ioremap() the memory so it needs to
know the BAR.
I mean a default bar address for --shmem device. Yes, guest needs to know
this address, but even if we specify the address at command line the guest
still
does not know this address, no? So having a default bar address does no
harm.
How does the user discover what the default BAR is? Which default BAR
should we use? I don't think default BAR adds much value here.
1. Print it on startup like, like we do for --name.
# kvm run -k ./bzImage -m 448 -c 4 --name guest-26676 --shmem bar=0xc8000000
or
2. kvm stat --shmem
David has chosen a default BAR already.
#define SHMEM_DEFAULT_ADDR (0xc8000000)
OK. Makes sense.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
