On Sun, 21 Jun 2009 04:02:15 am Christoph Hellwig wrote:
> Looks like I sent a patch that doesn't actually compile because qui
> decided to apply those fixes to a different one. Here's the correc
> one:
>
> --
>
> Subject: virtio_blk: don't bounce highmem requests
> From: Christoph Hellwig
>
> By
On Sun, 21 Jun 2009 04:59:41 am Christoph Hellwig wrote:
> Block driver ioctl methods must return ENOTTY and not -ENOIOCTLCMD if
> they expect the block layer to handle generic ioctls.
>
> This triggered a BLKROSET failure in xfsqa #200.
Applied.
Thanks,
Rusty.
--
To unsubscribe from this list: s
Bugs item #2810749, was opened at 2009-06-23 09:23
Message generated for change (Tracker Item Submitted) made by elfe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2810749&group_id=180599
Please note that this message will contain a full copy of the com
On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
> +static int
> +iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
> + int is_write)
> +{
> + struct _iosignalfd_group *p = to_group(this);
> +
> + return ((addr >= p->addr && (ad
On 06/22/2009 07:08 PM, Michael S. Tsirkin wrote:
On Mon, Jun 22, 2009 at 11:45:00AM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
It seems that a lot of complexity and trickiness with iosignalfd is
handling the group/item relationship, which comes about because kvm does
not
On 06/22/2009 07:29 PM, Gregory Haskins wrote:
We actually already have aliasing: is_write flag is used for this
purpose.
Yes, but read/write address aliasing is not the same thing is
multi-match data aliasing. Besides, your proposal also breaks some of
the natural relationship models (e
On 06/23/2009 11:56 AM, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
+static int
+iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
+ int is_write)
+{
+ struct _iosignalfd_group *p = to_group
On 06/23/2009 12:47 AM, Andre Przywara wrote:
KVM defaults to the hypervisor CPUID bit to be set, whereas pure QEMU clears
it. On some occasions one want to set or clear it the other way round (for
instance to get HyperV running inside a guest).
Allow the default to be overridden on the command l
On 06/23/2009 12:47 AM, Andre Przywara wrote:
Although the guest's CPUID bits can be controlled in a fine grained way
in QEMU, a simple way to inject the host CPU is missing. This is handy
for KVM desktop virtualization, where one wants the guest to support the
full host feature set.
Introduce an
On Tue, Jun 23, 2009 at 12:57:53PM +0300, Avi Kivity wrote:
> On 06/23/2009 11:56 AM, Michael S. Tsirkin wrote:
>> On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
>>
>>> +static int
>>> +iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
>>> +
Beth Kon wrote:
> Avi Kivity wrote:
>> On 06/22/2009 12:14 PM, Jan Kiszka wrote:
> Hmm, stead of introducing a new pair of singe-purpose IOCTLs, why not
> add KVM_GET/SET_PIT2 which exchanges an extended kvm_pit_state2. And
> that struct should also include some flags field and enough p
Bugs item #2810749, was opened at 2009-06-23 09:23
Message generated for change (Comment added) made by elfe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2810749&group_id=180599
Please note that this message will contain a full copy of the comment thre
On 06/23/2009 01:48 PM, Michael S. Tsirkin wrote:
On Tue, Jun 23, 2009 at 12:57:53PM +0300, Avi Kivity wrote:
On 06/23/2009 11:56 AM, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
+static int
+iosignalfd_group_in_range(struct kvm_
On Tuesday 23 June 2009, Avi Kivity wrote:
> On 06/23/2009 12:47 AM, Andre Przywara wrote:
> > KVM defaults to the hypervisor CPUID bit to be set, whereas pure QEMU
> > clears it. On some occasions one want to set or clear it the other way
> > round (for instance to get HyperV running inside a gues
Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
>
>> +static int
>> +iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
>> + int is_write)
>> +{
>> +struct _iosignalfd_group *p = to_group(this);
>> +
>>
On 06/23/2009 02:31 PM, Paul Brook wrote:
On Tuesday 23 June 2009, Avi Kivity wrote:
On 06/23/2009 12:47 AM, Andre Przywara wrote:
KVM defaults to the hypervisor CPUID bit to be set, whereas pure QEMU
clears it. On some occasions one want to set or clear it the other way
round (for in
On Tue, Jun 23, 2009 at 07:33:07AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
> >
> >> +static int
> >> +iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
> >> +int is
Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2009 at 07:33:07AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
>>>
>>>
+static int
+iosignalfd_group_in_range(struct kvm_io_device *this,
Avi Kivity wrote:
> On 06/22/2009 07:08 PM, Michael S. Tsirkin wrote:
>> On Mon, Jun 22, 2009 at 11:45:00AM -0400, Gregory Haskins wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
It seems that a lot of complexity and trickiness with iosignalfd is
handling the group/item relationship,
> I agree it's pointless, but it is a Microsoft requirement for passing
> their SVVP tests. Enabling it by default makes life a little easier for
> users who wish to validate their hypervisor and has no drawbacks.
I wasn't arguing against setting it by default (for QEMU CPU types), just
against
On Tue, Jun 23, 2009 at 12:04:06AM -0400, Gregory Haskins wrote:
> >> It will also need to support
> >> multiple matches.
> >>
> >
> > What, signal many fds on the same address/value pair?
> > I see this as a bug. Why is this a good thing to support?
> > Just increases the chance of leaking t
On Tue, Jun 23, 2009 at 07:41:12AM -0400, Gregory Haskins wrote:
> Avi Kivity wrote:
> > On 06/22/2009 07:08 PM, Michael S. Tsirkin wrote:
> >> On Mon, Jun 22, 2009 at 11:45:00AM -0400, Gregory Haskins wrote:
> >>
> >>> Michael S. Tsirkin wrote:
> >>>
> It seems that a lot of complexit
On 06/23/2009 07:04 AM, Gregory Haskins wrote:
Well, for one its not very clear what the benefit of the read/write
aliasing even is. ;) Apparently coalesced_mmio uses it, but even so I
doubt that is for the purposes of having one device do reads while
another does writes. I could be wrong, thou
Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2009 at 12:04:06AM -0400, Gregory Haskins wrote:
>
It will also need to support
multiple matches.
>>> What, signal many fds on the same address/value pair?
>>> I see this as a bug. Why is this a good thing to support?
On 06/23/2009 02:44 PM, Michael S. Tsirkin wrote:
On Tue, Jun 23, 2009 at 12:04:06AM -0400, Gregory Haskins wrote:
It will also need to support
multiple matches.
What, signal many fds on the same address/value pair?
I see this as a bug. Why is this a good thing to support?
Just
Avi Kivity wrote:
> On 06/23/2009 02:44 PM, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2009 at 12:04:06AM -0400, Gregory Haskins wrote:
>>
> It will also need to support
> multiple matches.
>
>
What, signal many fds on the same address/value pair?
I see th
On 06/23/2009 02:57 AM, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6
month release cycle, that would put 0.11.0 at September 2nd.
Based on the experiences with the stable rel
On 06/23/2009 03:01 PM, Gregory Haskins wrote:
Ok, so for now I will just crank up the io_bus array, and we can address
scale another day. Can I just drop patch 2/3 and let the io_bus govern
the limit?
So long as we have a runtime-discoverable limit, yes.
--
error compiling committee.c: t
KVM defaults to the hypervisor CPUID bit to be set, whereas pure
QEMU clears it. On some occasions one wants to set or clear it the
other way round (for instance to get HyperV running inside a guest).
Move the bit-set to be done before the command line parsing and
enable it by default. One can dis
Hello,
Here are two patches. One implements a virtio-serial device in qemu
and the other is the driver for a guest kernel.
While working on a vmchannel interface that is needed for communication
between guest userspace and host userspace, I saw that most of the
interface can be abstracted out as
This interface presents a char device from which bits can be
sent and read.
Sample uses for such a device can be obtaining info from the
guest like the file systems used, apps installed, etc. for
offline usage and logged-in users, clipboard copy-paste, etc.
for online usage.
Signed-off-by: Amit S
We expose multiple char devices ("ports") for simple communication
between the host userspace and guest.
This is mainly intended for obtaining information from the guest.
Sample offline usages can be: poking around in a guest to find out
the file systems used, applications installed, etc. Online u
> Here are two patches. One implements a virtio-serial device in qemu
> and the other is the driver for a guest kernel.
So I'll ask again. Why is this separate from virtio-console?
Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.ke
On (Tue) Jun 23 2009 [13:55:52], Paul Brook wrote:
> > Here are two patches. One implements a virtio-serial device in qemu
> > and the other is the driver for a guest kernel.
>
> So I'll ask again. Why is this separate from virtio-console?
I'm basically writing a vmchannel and found out that a lo
On Tuesday 23 June 2009, Amit Shah wrote:
> On (Tue) Jun 23 2009 [13:55:52], Paul Brook wrote:
> > > Here are two patches. One implements a virtio-serial device in qemu
> > > and the other is the driver for a guest kernel.
> >
> > So I'll ask again. Why is this separate from virtio-console?
>
> I'm
Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2009 at 08:30:46PM -0400, Gregory Haskins wrote:
>
>> +static int
>> +iosignalfd_group_in_range(struct kvm_io_device *this, gpa_t addr, int len,
>> + int is_write)
>> +{
>> +struct _iosignalfd_group *p = to_group(this);
>> +
>>
Am Dienstag 23 Juni 2009 14:55:52 schrieb Paul Brook:
> > Here are two patches. One implements a virtio-serial device in qemu
> > and the other is the driver for a guest kernel.
>
> So I'll ask again. Why is this separate from virtio-console?
I did some work on virtio-console, since kvm on s390 do
On Tuesday 23 June 2009, Christian Bornträger wrote:
> Am Dienstag 23 Juni 2009 14:55:52 schrieb Paul Brook:
> > > Here are two patches. One implements a virtio-serial device in qemu
> > > and the other is the driver for a guest kernel.
> >
> > So I'll ask again. Why is this separate from virtio-co
Andre Przywara wrote:
KVM defaults to the hypervisor CPUID bit to be set, whereas pure
QEMU clears it. On some occasions one wants to set or clear it the
other way round (for instance to get HyperV running inside a guest).
Move the bit-set to be done before the command line parsing and
enable it
On Mon, 22 Jun 2009, Gregory Haskins wrote:
> To be honest, I am not sure. I would guess its not a *huge* deal,
> though it was obviously enough of a concern to at least discuss it. I
> can definitely say that I think the other issues which are being fixed
> are substantially more important.
Ok
Davide Libenzi wrote:
> On Mon, 22 Jun 2009, Gregory Haskins wrote:
>
>
>> To be honest, I am not sure. I would guess its not a *huge* deal,
>> though it was obviously enough of a concern to at least discuss it. I
>> can definitely say that I think the other issues which are being fixed
>> are
On Tue, 23 Jun 2009, Rusty Russell wrote:
> The first 'struct eventfd_ctx;' line is not required.
Will repost dropping that.
- Davide
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
Am Dienstag 23 Juni 2009 16:16:13 schrieb Paul Brook:
> > I did some work on virtio-console, since kvm on s390 does not provide any
> > other. I dont think we should mix two different types of devices into one
> > driver. The only thing that these drivers have in common, is the fact
> > that there
On Tue, 23 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
> > On Mon, 22 Jun 2009, Gregory Haskins wrote:
> >
> >
> >> To be honest, I am not sure. I would guess its not a *huge* deal,
> >> though it was obviously enough of a concern to at least discuss it. I
> >> can definitely say
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>> On Mon, 22 Jun 2009, Gregory Haskins wrote:
>>>
>>>
>>>
To be honest, I am not sure. I would guess its not a *huge* deal,
though it was obviously enough of a concern
Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
>
>
>> And note that multiple works can run on irqfd
>> in parallel.
>>
>>
>
> They can? I thought work-queue items were guaranteed to only schedule
> once? If what you say is true, its broken, I agree, and Ill need to
> revisit. Let
Remove in_range from kvm_io_device and ask read/write callbacks, if
supplied, to perform range checks internally. This allows aliasing
(mostly for in-kernel virtio), as well as better error handling by
making it possible to pass errors up to userspace. And it's enough to
look at the diffstat to see
On Tue, Jun 23, 2009 at 01:55:52PM +0100, Paul Brook wrote:
> > Here are two patches. One implements a virtio-serial device in qemu
> > and the other is the driver for a guest kernel.
>
> So I'll ask again. Why is this separate from virtio-console?
In the guest I wouldn't want virtio-serial devic
On Tue, Jun 23, 2009 at 07:35:00AM -0700, Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Gregory Haskins wrote:
>
> > Davide Libenzi wrote:
> > > On Mon, 22 Jun 2009, Gregory Haskins wrote:
> > >
> > >
> > >> To be honest, I am not sure. I would guess its not a *huge* deal,
> > >> though it was
On 6/23/09, Anthony Liguori wrote:
> Hi,
>
> It's getting to be about the time to start thinking about the 0.11.0
> release. 0.10.0 was released on March 2nd so following with the 6 month
> release cycle, that would put 0.11.0 at September 2nd.
>
> Based on the experiences with the stable relea
On 6/23/09, Amit Shah wrote:
> We expose multiple char devices ("ports") for simple communication
> between the host userspace and guest.
> +struct virtio_serial_config {
> + __u32 nr_ports;
> + __u16 status;
> +} __attribute__((packed));
There is still structure packing. I'd use
On 6/23/09, Amit Shah wrote:
> This interface presents a char device from which bits can be
> sent and read.
> +struct virtio_serial_config
> +{
> +uint32_t nr_ports;
> +uint16_t status;
> +} __attribute__((packed));
Obviously this has to match the kernel structure if you go for 16
Michael S. Tsirkin wrote:
> Remove in_range from kvm_io_device and ask read/write callbacks, if
> supplied, to perform range checks internally. This allows aliasing
> (mostly for in-kernel virtio), as well as better error handling by
> making it possible to pass errors up to userspace. And it's eno
From: Christian Borntraeger
Since
commit 854b5338196b1175706e99d63be43a4f8d8ab607
Author: Christian Ehrhardt
KVM: s390: streamline memslot handling
s390 uses the values of the memslot instead of doing everything in the arch
ioctl handler of the KVM_SET_USER_MEMORY_REGION. Unfortunately we m
Hello Avi,
here are three patches against kvm.git that fix several issues in our
kvm port. Please review and consider all patches for 2.6.31.
Christian
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
From: Christian Borntraeger
This patch fixes the following warnings that were introduced by
commit 2921292f45733bccdb53e426bcf65ceb13f53d94
Author: Gleb Natapov
KVM: Use macro to iterate over vcpus.
arch/s390/kvm/kvm-s390.c: In function 'kvm_arch_set_memory_region':
arch/s390/kvm/kvm-s390.c
From: Christian Borntraeger
2.6.31-rc introduced an architecture level set checker based on facility
bits. e.g. if the kernel is compiled to run only on z9, several facility
bits are checked very early and the kernel refuses to boot if a z9 specific
facility is missing.
Until now kvm on s390 did
On Tue, Jun 23, 2009 at 11:21:53AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > Remove in_range from kvm_io_device and ask read/write callbacks, if
> > supplied, to perform range checks internally. This allows aliasing
> > (mostly for in-kernel virtio), as well as better error hand
Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2009 at 11:21:53AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> Remove in_range from kvm_io_device and ask read/write callbacks, if
>>> supplied, to perform range checks internally. This allows aliasing
>>> (mostly for in-ke
Blue Swirl wrote:
On 6/23/09, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6 month
release cycle, that would put 0.11.0 at September 2nd.
Based on the experiences with the
On 06/23/2009 06:09 PM, Blue Swirl wrote:
I think this is great, but OpenBIOS still uses Subversion. Can git use
SVN submodules for example?
No, but we could have a git svn mirror and include that.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
On Tue, Jun 23, 2009 at 11:44:57AM -0400, Gregory Haskins wrote:
> >> This proposed approach forces us into a
> >> potential O(256) algorithm in the hotpath (all MMIO/PIO exits will hit
> >> this, not just in-kernel users). How would you address this?
> >>
> >
> > Two ideas that come to mind
Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2009 at 11:44:57AM -0400, Gregory Haskins wrote:
>
This proposed approach forces us into a
potential O(256) algorithm in the hotpath (all MMIO/PIO exits will hit
this, not just in-kernel users). How would you address this?
>>
Hi Joerg,
On Fri, Jun 19, 2009 at 03:16:24PM +0200, Joerg Roedel wrote:
> With the new name and the corresponding backend changes this function
> can now support multiple hugepage sizes.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/kvm/mmu.c | 100 +-
On Fri, Jun 19, 2009 at 03:16:23PM +0200, Joerg Roedel wrote:
> /*
> @@ -724,11 +724,11 @@ static int kvm_handle_hva(struct kvm *kvm, unsigned
> long hva,
> end = start + (memslot->npages << PAGE_SHIFT);
> if (hva >= start && hva < end) {
> gfn_t
On Fri, Jun 19, 2009 at 03:16:26PM +0200, Joerg Roedel wrote:
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/kvm_host.h |2 +-
> arch/x86/kvm/mmu.c | 60
> ++-
> arch/x86/kvm/paging_tmpl.h |6 ++--
> 3 files changed, 38
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes away.
Also, now the internal eventfd APIs are
On Tue, Jun 23, 2009 at 12:59:33PM -0300, Marcelo Tosatti wrote:
> Hi Joerg,
>
> On Fri, Jun 19, 2009 at 03:16:24PM +0200, Joerg Roedel wrote:
> > gfn = unalias_gfn(kvm, gfn);
> > - write_count = slot_largepage_idx(gfn,
> > -gfn_to_memslot_unaliased(kvm, g
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last instance of the file* goes away.
> Also, n
On 6/23/09, Anthony Liguori wrote:
> Dustin Kirkland was kind enough to setup a bug tracker for QEMU on
> Launchpad. I would like to make this the official QEMU bug tracker unless
> there is significant objection.
The links on code tab do not show which is our tree and there are some
Ubuntu tree
On 06/23/2009 07:47 PM, Davide Libenzi wrote:
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes
On Tue, 2009-06-23 at 20:02 +0300, Blue Swirl wrote:
> On 6/23/09, Anthony Liguori wrote:
> > Dustin Kirkland was kind enough to setup a bug tracker for QEMU on
> > Launchpad. I would like to make this the official QEMU bug tracker unless
> > there is significant objection.
>
> The links on code
On Tue, 23 Jun 2009, Avi Kivity wrote:
> On 06/23/2009 07:47 PM, Davide Libenzi wrote:
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to racely free handle the
> > POL
On Tue, Jun 23, 2009 at 01:47:28PM -0300, Marcelo Tosatti wrote:
> On Fri, Jun 19, 2009 at 03:16:26PM +0200, Joerg Roedel wrote:
> > @@ -254,7 +254,7 @@ static int is_last_spte(u64 pte, int level)
> > {
> > if (level == PT_PAGE_TABLE_LEVEL)
> > return 1;
> > - if (level == PT_DIR
On Tue, 23 Jun 2009, Randy Dunlap wrote:
> kernel-doc syntax requires the function name + short description on one line,
> followed by parameters. Any longer function description then comes after
> the parameters.
>
> See Documentation/kernel-doc-nano-HOWTO.txt for more info,
> or ask me.
Will
I see that Rhel5.3 32 and 64 bit guests fail to boot with virtio for
block device. The
guest can not find the root filesystem. The guest is using LVM. As per
the linux-kvm wiki instructions I did change device.map and booted
with if=virtio.
The wiki link is http://www.linux-kvm.org/page/Boot_from_
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last instance of the file* goes away.
> Also, n
On Tue, 23 Jun 2009, Gregory Haskins wrote:
> I think the lack of a way to got from a file* to a ctx* (or back) might
> be a problem. I am not an expert, but if I understood the gist of what
> Al Viro (cc'd) was saying early on, an fd can change meaning out from
> under you without warning.
>
>
Correct missing locking in a few places in x86's vm_ioctl handling path.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/x86.c
===
--- kvm.orig/arch/x86/kvm/x86.c
+++ kvm/arch/x86/kvm/x86.c
@@ -1951,19 +1951,25 @@ static int
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes away.
Also, now the internal eventfd APIs are
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to rac
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> Another cleanup this patch does, is making AIO select EVENTFD, instead of
> adding a bunch of empty function stubs inside eventfd.h in order to
> handle the (AIO && !EVENTFD) case.
Given that we're trying to squeak this patch int
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > Another cleanup this patch does, is making AIO select EVENTFD, instead of
> > adding a bunch of empty function stubs inside eventfd.h in order to
> > handle the (AIO && !EVENTFD)
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to rac
On Tue, 23 Jun 2009 13:59:07 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > Another cleanup this patch does, is making AIO select EVENTFD, instead of
> > > adding a bunch of empty
On Tue, 23 Jun 2009 14:03:22 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > The following patch changes the eventfd interface to de-couple the
> > > eventfd
> > > memory context,
On Tue, 23 Jun 2009, Andrew Morton wrote:
> That isn't for us to decide. Entire syscalls can be disabled in config.
That is not a well defined separate syscall though. It's a member/feature
of the aiocb.
- Davide
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
On Tue, 23 Jun 2009, Andrew Morton wrote:
> > > > +struct eventfd_ctx *eventfd_ctx_get(struct eventfd_ctx *ctx)
> > > > +{
> > > > + kref_get(&ctx->kref);
> > > > + return ctx;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(eventfd_ctx_get);
> > >
> > > doesn't match the code.
>
> You appear
On Tue, 23 Jun 2009, Andrew Morton wrote:
> > Should functions be describing all the returned error codes, ala man pages?
> >
>
> I think so.
This becomes pretty painful when the function calls other functions, for
which just relays the error code.
Should we be just documenting the error codes
On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > That isn't for us to decide. Entire syscalls can be disabled in config.
>
> That is not a well defined separate syscall though. It's a member/feature
> of the aiocb.
I don't know w
On Tue, 23 Jun 2009 14:34:50 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > > Should functions be describing all the returned error codes, ala man
> > > pages?
> > >
> >
> > I think so.
>
> This becomes pretty painful when the function calls other functio
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 14:34:50 -0700 (PDT)
> Davide Libenzi wrote:
>
> > On Tue, 23 Jun 2009, Andrew Morton wrote:
> >
> > > > Should functions be describing all the returned error codes, ala man
> > > > pages?
> > > >
> > >
> > > I think so.
> >
>
On Tue, 23 Jun 2009 14:48:51 -0700 (PDT)
Davide Libenzi wrote:
> > > This becomes pretty painful when the function calls other functions, for
> > > which just relays the error code.
> > > Should we be just documenting the error codes introduced by the function
> > > code, and say that the funct
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes away.
Also, now the internal eventfd APIs are
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
> Davide Libenzi wrote:
>
> > On Tue, 23 Jun 2009, Andrew Morton wrote:
> >
> > > That isn't for us to decide. Entire syscalls can be disabled in config.
> >
> > That is not a well defined separate syscall tho
On Tue, 23 Jun 2009 15:49:53 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > On Tue, 23 Jun 2009, Andrew Morton wrote:
> > >
> > > > That isn't for us to decide. Entire syscalls ca
Michael S. Tsirkin wrote:
> Remove in_range from kvm_io_device and ask read/write callbacks, if
> supplied, to perform range checks internally. This allows aliasing
> (mostly for in-kernel virtio), as well as better error handling by
> making it possible to pass errors up to userspace. And it's eno
On Tue, 23 Jun 2009 03:33:22 am Davide Libenzi wrote:
> What you're doing there, is setting up a kernel-to-kernel (since
> userspace only role is to create the eventfd) communication, using a file*
> as accessory. That IMO is plain wrong.
The most sensible is that userspace can use these fds; an i
1 - 100 of 103 matches
Mail list logo
