On Monday 07 April 2008, Hollis Blanchard wrote:
--- a/include/asm-powerpc/kvm.h
+++ b/include/asm-powerpc/kvm.h
@@ -1,6 +1,55 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ *
On Tuesday 11 December 2007, Avi Kivity wrote:
Heiko Carstens wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
arch/*/kvm/ arch dependent kvm code
Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
There will be several kvm files in
On Tuesday 20 November 2007, Avi Kivity wrote:
Sorry for being late in this thread.
We (s390) will need a hypercall as we do not have port I/O. I think it
should be
possible to default to hypercall on s390 and use pio everywhere else.
Or be generic: advertise the methods
On Thursday 08 November 2007, Anthony Liguori wrote:
They already show up underneath of the PCI bus. The issue is that there
are two separate 'struct device's for each virtio device. There's the
PCI device (that's part of the pci_dev structure) and then there's the
virtio_device one. I
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's own device.
*/
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's own device.
*/
On Monday 05 November 2007, Carsten Otte wrote:
Dong, Eddie wrote:
BTW, why we use vector here? shouldn't it be irq_line or irq_no?
Maybe you mean the Channel Subsystem (1st piece of knowledge and
surprise known from s390 doc) are emulated in Qemu, correct?
The vector field was
On Monday 05 November 2007, Carsten Otte wrote:
Actually, you have neither irq numbers nor vectors on s390 right now.
I/O subchannels are do not fit into the IRQ handling in Linux at
all, and external interrupts are sufficiently different that you
should not treat them as IRQ lines in
On Friday 12 October 2007, Carsten Otte wrote:
This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
I assume the contents are ok, since you're just moving code around, but
please
signed-off-by: Carsten Otte
On Tuesday 25 September 2007, Rusty Russell wrote:
On Tue, 2007-09-25 at 00:18 +0200, Arnd Bergmann wrote:
This is a pattern I've seen a few times before, but could never understand
what it's good for. What is your reason for defining a new data structure
that is used only once, instead
On Monday 24 September 2007, Rusty Russell wrote:
This attempts to implement a virtual I/O layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
Hi Rusty,
Thanks for your update, as you can imagine, I'm
On Thursday 20 September 2007, Rusty Russell wrote:
+ * virtio_driver - operations for a virtio I/O driver
+ * @name: the name of the driver (KBUILD_MODNAME).
+ * @owner: the module which contains these routines (ie. THIS_MODULE).
+ * @id_table: the ids (we re-use PCI ids) serviced by this
On Friday 21 September 2007, Rusty Russell wrote:
Hmm, I guess we could have a PCI driver which claims all VIRTIO vendor
devices.
yes, that was the idea.
Then it can call virtio_find_driver() (?) at the top of its
probe function to find if there's a matching virtio driver.
This PCI
On Tuesday 28 August 2007, Eric Van Hensbergen wrote:
This adds a shared memory transport for a synthetic 9p device for
paravirtualized file system support under KVM/QEMU.
Nice driver. I'm hoping we can do a virtio driver using a similar
concept.
+#define PCI_VENDOR_ID_9P 0x5002
On Saturday 25 August 2007, Dor Laor wrote:
+static int debug = 3;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, Debug level (0=none,...,16=all));
+
+#define DPRINTK(klevel, fmt, args...) \
+ if (('0' + debug) = (int)(klevel[1])) \
+ printk(klevel %s:%d: fmt, \
+
On Wednesday 18 July 2007, Avi Kivity wrote:
Once we're back to using fds, we might as well use ioctls. If anything,
an ioctl has an explicit mention of the structure it manipulates in its
definition. I don't care that it came in last in the last 15 annual
kernel beauty contests.
For
On Wednesday 18 July 2007, Gerd Hoffmann wrote:
Rusty Russell wrote:
You mean backend? For networking it makes a great deal of sense. For
block it makes far less sense (COW, weird formats, etc).
For block you probably want both: userspace driver which can handle all
sorts of funny
On Thursday 19 July 2007, Anthony Liguori wrote:
Interestingly, once you have the kernel driver that maps a block device,
you can do most of the useful user scenarios by means of /dev/loop
and/or device mapper.
Not quite. Using device mapper to implement something like qcow turns
out
On Saturday 16 June 2007, Rusty Russell wrote:
This is a bonus patch for those wondering how a virtio implementation
can look.
Thanks, I assumed it was something like this, but having the code
in front of me makes it a lot easier to comment on it.
+static struct lguest_driver
On Thursday 14 June 2007, Caitlin Bestler wrote:
Why not simply adopt the policy that if the IOMMU does not meet
the security requirements of the Hypervisor then it is not an
IOMMU as far as the Hypervisor is concerned?
More specificially, the Hypervisor should enable direct access
by a
On Sunday 10 June 2007, Avi Kivity wrote:
There are probably more. Any ideas?
* watchdog timer
* tty ports (not just console) to attach to via host socket
* alsa
* hostfs (UML like)
Arnd
-
This SF.net email is
On Sunday 10 June 2007, Avi Kivity wrote:
- PCI (or your favorite HW bus) passthrough, for your favorite oddball
device (e.g., crypto-accelerators).
Won't all high-bandwidth traffic be through dma, bypassing virtio?
It can be done, but you'd also need a passthrough for the IOMMU
in
On Wednesday 13 June 2007, Caitlin Bestler wrote:
It can be done, but you'd also need a passthrough for the
IOMMU in that case, and you get a potential security hole: if
a malicious guest is smart enough to figure out IOMMU
mappings from the device to memory owned by the host.
If it
On Wednesday 06 June 2007, Carsten Otte wrote:
Dor Laor wrote:
Now that more platforms are joining the KVM wagon, we should define a
common bus. PCI was a overkill anyway - its irq are shared and we don't
have to use its io/mmio areas.
Do you guys have something to start with?
We do
On Wednesday 23 May 2007, Eric Van Hensbergen wrote:
On 5/23/07, Carsten Otte [EMAIL PROTECTED] wrote:
For me, plan9 does provide answers to a lot of above requirements.
However, it does not provide capabilities for shared memory and it
adds extra complexity. It's been designed to solve a
On Monday 21 May 2007, Cornelia Huck wrote:
IRQ numbers are evil :)
yes, but getting rid of them is an entirely different discussion.
I really think that in the first step, you should be able to
use its external interrupts with the same request_irq interface
as the other architectures.
On Friday 11 May 2007, Carsten Otte wrote:
This patch adds support for a new bus type that manages paravirtualized
devices. The bus uses the s390 diagnose instruction to query devices, and
match them with the corresponding drivers.
It seems that the diagnose instruction is really the only
On Sunday 06 May 2007, Wink Saville wrote:
+Atomic Code Execution (ACE) allows code to execute as if it was
+surrounded by spin_lock_irqsave and spin_unlock_irqrestore without
+requiring actual access to the processor flags register.
I guess you mean spin_{un,}lock_irq here, right? The
On Sunday 06 May 2007, Wink Saville wrote:
Thus code
+executing within the ACE area can also be executed from user space or
+kernel space. This is accomplished by using spin locks when executing
+within the ACE area and changes to arch/x86_64/kernel/entry.S such that
+when an
On Sunday 29 April 2007, Heiko Carstens wrote:
Is this data structure extensible? If it is, you probably need
some sort of versioning information to make sure that user space
doesn't rely on fields that the kernel doesn't know about.
I don't think we can put in some versioning
On Friday 27 April 2007, Carsten Otte wrote:
Add interface which allows a process to start a virtual machine.
Looks pretty good to me already.
It seems a lot closer to lguest than to kvm at the moment concerning
the kernel interfaces (guest real address == host process, state
is attached to
On Thursday 05 April 2007, Dor Laor wrote:
For example, lets says you are running several guests, and would
like
to
start yet another one for a while - but have no free memory left.
We have another solution for it that will soon be pushed into the
kernel:
It is the balloon driver
On Thursday 05 April 2007, Dor Laor wrote:
Currently the only memory-over-commit mechanism is the balloon.
In the future we will add all the wise spectrum of host demand pages,
shared pages, etc.
Ok, just as another hint: you should definitely take a look at
pfault_interrupt() in
On Thursday 05 April 2007, Avi Kivity wrote:
arch/s390/mm/extmem.c has another very interesting concept, though the
hcall interfaces used there are not as flexible as they should be in
kvm. It's basically about mapping host files into the guest real address
space, e.g. for shared memory
On Wednesday 28 March 2007, Hollis Blanchard wrote:
I don't see a big difference between the ioctl layer and libkvm. In
general, a libkvm function is an ioctl, and kvm_callback members are a
decoding of kvm_run fields. If you edit kvm_run to suit your needs, you
can probably reuse
On Tuesday 20 March 2007, Avi Kivity wrote:
Managing userspace in subversion and the kernel in git is proving to be
quite a pain. Branches have to be maintained in parallel, tagging is
awkward, and bisection is fairly impossible.
What do people think about putting libkvm and qemu into the
On Tuesday 20 March 2007, Avi Kivity wrote:
I find using a patch queue useful though for submitting things
upstream. A good example is our QEMU changes. It's a real pain to
break apart the SVN history into individual patches.
Why not just extract diffs with 'svn diff'? That's what I
On Monday 22 January 2007 11:21, Klaas van Gend wrote:
Maybe this can be done without much setup costs, by asking the
maintainer of kernel.org.
At least rt.wiki.kernel.org exists and is being used by the community.
As KVM has rather similar usage patterns, I can easily imagine that we
could
On Tuesday 09 January 2007 14:37, Avi Kivity wrote:
struct kvm_vcpu_area {
u32 vcpu_area_size;
u32 exit_reason;
sigset_t sigmask; // for use during vcpu execution
Since Jeff brought up the point of 32 bit compatibility:
When this structure is shared between 64 bit kernel and
32
On Thursday 09 November 2006 14:36, Avi Kivity wrote:
I'm not an expert on inline assembly, but don't you need an extra
'm (phys_addr)' to make sure that gcc actually puts the variable
on the stack instead of passing a NULL pointer as 'a(phys_addr)'?
Taking a variable's address should
On Wednesday 08 November 2006 14:46, Muli Ben-Yehuda wrote:
Yes. I'm not quite sure why you would want to do this though, except
maybe because it's possible and thus someone, somewhere wants to see
it done.
I don't know what tools exist for debugging xen itself, but I could
imagine that it's
41 matches
Mail list logo
