On Friday 08 February 2008, Christian Borntraeger wrote:
> Currently the virtio_ring structure are not declared packed, but they
> describe an hardware like interface. We should not allow compilers to make
> alignments and optimizations that can be different between the guest and
> host compile
On Sunday 10 February 2008, you wrote:
> Christian Borntraeger wrote:
> > struct vring_used
> > {
> > __u16 flags;
> > __u16 idx;
> > + __u32 padding;
> > struct vring_used_elem ring[];
> > -};
> > +} __attribute__ ((packed));
> >
>
> This padding that you've put in is n
On Monday 10 March 2008, Christian Borntraeger wrote:
> include/asm-alpha/Kbuild | 1 +
> include/asm-alpha/kvm.h | 6 ++
> include/asm-arm/Kbuild | 2 ++
> include/asm-arm/kvm.h | 6 ++
> include/asm-avr32/Kbuild | 1 +
> include/asm-avr32/kvm.h
On Tuesday 25 March 2008, Carsten Otte wrote:
> +
> +static inline void __user *__guestaddr_to_user(struct kvm_vcpu *vcpu,
> +u64 guestaddr)
> +{
> + u64 prefix = vcpu->arch.sie_block->prefix;
> + u64 origin = vcpu->kvm->arch.guest_origin;
> +
On Tuesday 25 March 2008, Carsten Otte wrote:
> + case KVM_S390_SIGP_SET_PREFIX:
> + VCPU_EVENT(vcpu, 4, "interrupt: set prefix to %x",
> +inti->prefix.address);
> + vcpu->stat.deliver_prefix_signal++;
> + vcpu->arch.sie_block->prefix
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
> + * pu
On Tuesday 08 April 2008, Hollis Blanchard wrote:
> If there is one thing I have learned in my various porting efforts, it's that
> using a variable-sized type in an interface is just begging for trouble.
>
> x86 uses fixed 64-bit variables here (even with x86-32), so that might be the
> right s
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 Monday 22 October 2007, Dong, Eddie wrote:
> Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis &
> Carsten?), but for IA64
> it is catagoried into low fp & high fp.
PPC can use that flag, on s390 it won't help.
Arnd <><
--
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
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
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 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
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
On Tuesday 27 November 2007, Avi Kivity wrote:
> > :-) Do you know if there is a hard limit on the number of devices on
> > a PCI bus? My concern was that it was limited by something stupid
> > like an 8-bit identifier.
>
> IIRC pci slots are 8-bit, but you can have multiple buses, so
> effec
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 seve
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
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?
>
On Wednesday 06 June 2007, Jun Koi wrote:
> About the balloon driver, I looked at the current code, and what I
> dont like is its approach: it needs to be operated from inside the
> guest, which is not the way we usually want to do. So something like
> Xen balloon driver is certainly better.
There
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
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.
>
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
>
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 lguest_virtnet
On Saturday 30 June 2007, ron minnich wrote:
> Somebody here at OLS was asking me about linuxbios on kvm. Well, that
> was too much to resist.
>
> Short form: it works, uses a grub-like interface that does not use
> BIOS callbacks. It's noticeably faster to boot than Bochs. I realize
> that it's a
On Tuesday 17 July 2007, Rusty Russell wrote:
> KVM interface is no longer experimental.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r 4e57f5c6d4a9 include/linux/kvm.h
> --- a/include/linux/kvm.h Tue Jul 17 13:04:58 2007 +1000
> +++ b/include/linux/kvm.h Tue Jul 17
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.
>
>
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 fun
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
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
> +#de
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:
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 Saturday 22 September 2007, Rusty Russell wrote:
> But now each virtio device has two "struct device"s, not one. And
> you've made up a fictional bus to do it.
>
> Yet for PCI systems, it really is a PCI device; exposing a second bus to
> userspace just because we put a layer in our implement
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
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
&
On Sunday 29 October 2006 14:31, Avi Kivity wrote:
> + r = -EEXIST;
> + if (vcpu->vmcs)
> + goto out_unlock;
> +
> + r = -ENOMEM;
> + filp = get_empty_filp();
> + if (!filp)
> + goto out_unlock;
> +
> + r = get_unused_fd();
> + i
On Monday 30 October 2006 10:08, Avi Kivity wrote:
> > Your concept of allocating
> > a new context on each open is already weird, but there have been other
> > examples of that before.
>
> Actually that seemed to me quite natural.
It's described in LDD2 and other books, but the traditional view i
On Wednesday 08 November 2006 10:32, Avi Kivity wrote:
> Another option is to use a small subset of kvm to run paravirtualized
> Xen guests on top of kvm (without Xen itself).
How about running Xen inside of kvm? Since kvm can do full
virtualization, it should work for all versions of Xen that
do
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
On Thursday 09 November 2006 12:08, Avi Kivity wrote:
> Index: linux-2.6/drivers/kvm/kvm_main.c
> ===
> --- linux-2.6.orig/drivers/kvm/kvm_main.c
> +++ linux-2.6/drivers/kvm/kvm_main.c
> @@ -369,8 +369,8 @@ static void vmcs_clear(struc
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
On Thursday 09 November 2006 15:52, Avi Kivity wrote:
> Wouldn't that make inline assembly useless? Suppose the contents is
> itself a pointer. What about the pointed-to contents?
>
> e.g.
>
> int x = 3;
> int *y = &x;
> int z;
>
> asm ("mov %1, %%rax; movl (%%rax), %0" : "=r"
On Thursday 16 November 2006 19:04, Avi Kivity wrote:
> +struct kvm_msr_entry {
> + __u32 index;
> + __u32 reserved;
> + __u64 data;
> +};
> +
> +/* for KVM_GET_MSRS and KVM_SET_MSRS */
> +struct kvm_msrs {
> + __u32 vcpu;
> + __u32 nmsrs; /* number of msrs in entries
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 an
On Tuesday 09 January 2007 14:47, Jeff Garzik wrote:
> Can we please avoid adding a ton of new ioctls? ioctls inevitably
> require 64-bit compat code for certain architectures, whereas
> sysfs/procfs does not.
For performance reasons, an ascii string based interface is not
desireable here, some
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
>
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
On Tuesday 20 March 2007, Avi Kivity wrote:
> How does that work with multiple developers?
You need a set of well-understood rules if more than one person
has commit access to the repository.
The most simple rule would be that everyone just adds patches at
the end of the quilt series. When you su
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
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 re
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:
>
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 arch/s390/m
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 me
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 th
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 inf
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 save/
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
> >
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 s
On Monday 14 May 2007, Anthony Liguori wrote:
> It seems like request_irq is roughly the same as
> register_external_interrupt. I suspect that you could get away with
> either patching hvc_console to use register_external_interrupt if
> CONFIG_S390 or perhaps providing a common interface.
>
>
On Monday 21 May 2007, Christian Borntraeger wrote:
> > This is quite easy with KVM. I like the approach that vmchannel has
> > taken. A simple PCI device. That gives you a discovery mechanism for
> > shared memory and an interrupt and then you can just implement a ring
> > queue using those
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.
Fundam
63 matches
Mail list logo