>>> I've never really thought much about them until now. What's the
case
>>> for supporting userspace hypercalls?
>>>
>>> The current way the code works is a little scary. Hypercalls that
>>> aren't handled by kernelspace are deferred to userspace. Of course,
>>> kernelspace has no idea whether
>> +static inline int
>> +__hypercall2(unsigned int nr, unsigned long p1, unsigned long p2)
>> +{
>> +int ret;
>> +asm (" call hypercall_addr\n"
>[...]
>> +return ret;
>
>Hello Dor,
>
>Linux system calls return long. I think hypercalls should behave in a
>similar
>manner and return long
>> +asm (" call hypercall_addr\n"
>
>Hi Dor,
>
>This cannot work, because hypercall_addr is currently not defined in
>todays
>kvm.git:
The definition is inside kvm_pv.c which was in the next patchset, I'll
join them in the next series. [Although Anthony L. has a different
method that
might c
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a copy
>
>Hi Dor,
>
>some of your patch lines seem line-wrapped. Is there place where I can
>download the whole series? Thanks
>
>Christian
The code can now be accessed by git:
git://kvm.qumranet.com/home/dor/src/virti
>I just noticed this:
>
>> --- /dev/null
>> +++ b/qemu/hw/paravirt_net.c
>> @@ -0,0 +1,213 @@
>> +/*
>> + * QEMU para virtual network emulation
>> + *
>> + * Copyright (c) 2007 Qumranet
>> + *
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a copy
>> + * of this soft
On Wed, 2007-08-29 at 04:31 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > @@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
> > }
> > sort_main_extable();
> > trap_init();
> > + kvm_guest_init();
> > rcu_init();
> > ini
On Wed, 2007-08-29 at 04:12 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > This patch refactors the current hypercall infrastructure to better support
> > live
> > migration and SMP. It eliminates the hypercall page by trapping the UD
> > exception tha
> And regarding the patches in the dos format, I tried sending patches to
> my yahoo/gmail account and I don't see them in the DOS format. It's
> strange it is reaching you in the DOS format. I don't know a way to
> avoid it right now. Please let me know if there is any known trick or
> method to a
Hi Avi,
Attached is the patch to implement emulation of instruction pushf,
opcode 0x9c.
Please apply or comment.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; i
Hi Avi,
Attached is the patch to implement instruction call near, opcode 0xe8.
Please apply or comment.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works muc
Hi Avi,
Attached is the patch to implement the push imm8 instruction opcode
0x6a.
Please apply or comment.
And regarding the patches in the dos format, I tried sending patches to
my yahoo/gmail account and I don't see them in the DOS format. It's
strange it is reaching you in the DOS format. I
>I don't really like the idea of having other modules register
>hypercalls. The hypercall address space is fixed and should be
>maintained by KVM.
The hypercall range is fixed, the registration is for modules that
dynamically
linked and for making sure the KVM module itself won't get unlinked in
>> > 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.
>>
>
>Yes. I'm looking at the patches from Dor now, it should be pretty
>straight forw
>>
>> Nice driver. I'm hoping we can do a virtio driver using a similar
>> concept.
>>
>> > +#define PCI_VENDOR_ID_9P 0x5002
>> > +#define PCI_DEVICE_ID_9P 0x000D
>>
>> Where do these numbers come from? Can we be sure they don't conflict
>with
>> actual hardware?
>
>I stole the VENDOR_ID fr
On 8/28/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> 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
On 8/28/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> 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
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 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 8/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
I just noticed this:
> --- /dev/null
> +++ b/qemu/hw/paravirt_net.c
> @@ -0,0 +1,213 @@
> +/*
> + * QEMU para virtual network emulation
> + *
> + * Copyright (c) 2007 Qumranet
> + *
> + * Permission is hereby granted, free of charge, to any person
>
On Tue, Aug 28, 2007 at 01:52:38PM -0500, Eric Van Hensbergen wrote:
> +config NET_9P_PCI
> + depends on NET_9P
> + tristate "9p PCI Shared Memory Transport (Experimental)"
shouldn't this depend on CONFIG_PCI?
-
This
Hi,
This patch adds the qemu side of the 9P over PCI transport that is
used to implement paravirtualized file system support for KVM/QEMU. In
order to compile the PCI device, you need to download and install the
spfs library (http://sourceforge.net/projects/npfs).
The kernel side of the transport
From: Eric Van Hensbergen <[EMAIL PROTECTED](none)>
This adds a 9p generic shared memory transport which has been used to
communicate between Dom0 and DomU under Xen as part of the Libra and PROSE
projects (http://www.research.ibm.com/prose).
Parts of the code are a horrible hack, but may be usef
From: Eric Van Hensbergen <[EMAIL PROTECTED](none)>
This patch abstracts out the interfaces to underlying transports so that
new transports can be added as modules. This should also allow kernel
configuration of transports without ifdef-hell.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]
From: Eric Van Hensbergen <[EMAIL PROTECTED](none)>
This adds a transport to 9p for communicating between guest and host
domains on lguest. Currently, the host-side proxies the communication to a
socket connected to the actual server. The transport is based heavily on
the existing console code.
From: Latchesar Ionkov <[EMAIL PROTECTED]>
This adds a shared memory transport for a synthetic 9p device for
paravirtualized file system support under KVM/QEMU.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
Documentation/filesystem
This patch set contains a set of virtualization transports for the 9p file
system intended to provide a mechanism for guests to access a portion of the
hosts name space without having to go through a virtualized network.
Shared memory based transports are provided for lguest using a variation of
On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> @@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
> }
> sort_main_extable();
> trap_init();
> + kvm_guest_init();
> rcu_init();
> init_IRQ();
> pidhash_init();
Hi Anthony,
This
On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support
> live
> migration and SMP. It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
On Mon, 2007-08-27 at 20:49 +0300, Alexey Eremenko wrote:
> Anthony Liguori wrote:
> >I've tested this on VT and it works nicely.
>
> Excuse me, but you said several months ago something about "kvm-xen",
> which doesn't requires VT CPUs.
>
> Will you publish or merge that technology ? (as I don'
-
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop
30 matches
Mail list logo
