On Thu, 11 Aug 2011 21:59:25 +0200
Dongsu Park wrote:
> Hi,
>
> On 07/28/2011 05:22 PM, Michael S. Tsirkin wrote:
> > On Thu, Jul 28, 2011 at 10:29:05PM +0800, Liu Yuan wrote:
> >> +static struct miscdevice vhost_blk_misc = {
> >> + 234,
> >
> > Don't get a major unless you really must.
>
> th
> Yeah, not sure what's going on here. Alan sent me the patch a while
> back in a private mail, so I asked him to resend it to the ML, so
> it's available for review. Next thing that happens is this mail a few
> weeks later.
I don't recall seeing your your reply and I really wasn't sure where it
n
> I wonder how many such bugs a memzero()/bzero() will prevent.
If the compiler-foo is possible with gcc then a 0 length constant
memset warning and a warning if the set value is > 255 would both
probably be useful.
Fortunately a lot of other validation/verification tools do pick it up
already.
From: Alan Cox
KVM_SET_SIGNAL_MASK passed a NULL argument leaves the on stack signal
sets uninitialized. It then passes them through to
kvm_vcpu_ioctl_set_sigmask.
We should be passing a NULL in this case not translated garbage.
Signed-off-by: Alan Cox
---
virt/kvm/kvm_main.c |7
From: Alan Cox
KVM_SET_SIGNAL_MASK passed a NULL argument leaves the on stack signal
sets uninitialized. It then passes them through to
kvm_vcpu_ioctl_set_sigmask.
We should be passing a NULL in this case not translated garbage.
Signed-off-by: Alan Cox
---
virt/kvm/kvm_main.c |7
> > ACKs, NACKs? What is happening here?
>
> I would like an Ack from Alan Cox who switched vhost-net
> to a dynamic minor in the first place, in commit
> 79907d89c397b8bc2e05b347ec94e928ea919d33.
Sorry dev...@lanana.org isn't yet back from the kernel hack incident.
> Also:
> - use C99 style initialization.
> - add missing entry in documentation for loop-control
>
> Signed-off-by: Stephen Hemminger
For the device allocation
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bo
> If the fd overhead really is a problem, perhaps the fd could be retained
> for setup operations, and omitted only on calls that require a vcpu to
> have been already set up on the current thread?
Quite frankly I'd like to have an fd because it means you've got a
meaningful way of ensuring that i
> >register_pio_hook_ptr_r(PIO_IDE, SIZE_BYTE,&s->cmd[0]);
> >for (i = 1; i< 7; i++) {
> > register_pio_hook_ptr_r(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
> > register_pio_hook_ptr_w(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
> >}
>
> You can't easily serialize updates to that address
> - Then, are we certain that there's no case where the tty layer will
> call us with some lock held or in an atomic context ? To be honest,
> I've totally lost track of the locking rules in tty land lately so it
> might well be ok, but something to verify.
Some of the less well behaved line disc
On Wed, 12 May 2010 18:29:57 -0700
Chris Wright wrote:
> The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
> check to verify privileges before allowing a user to read device
> dependent config space. This is meant to protect from an unprivileged
> user potentially locking
> +/*
> + * Map usr buffer at specific IO virtual address
> + */
> +static int vfio_dma_map_iova(
> + mlp = kzalloc(sizeof *mlp, GFP_KERNEL);
Not good at that point. I think you need to allocate it first, error if
it can't be allocated and then do the work and free it on error ?
> + ml
> It seems excessive. Most machines will hardly run without acpi.
*Recent* machines.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Linux is used a lot in embedded systems (like routers and NAS-es and
> probably set-top boxes). I guess the # of embedded systems with some
> linux flavour on it is substantially bigger than the desktop systems.
> Most of these are ARM or MIPS based and do not support ACPI.
They also don't supp
> Only common sense. Non-recent machines are barely usable these days.
> Sure they work well as a firewall or server-in-a-closet, but if you run
> a desktop or a server that actually does useful work, you're running a
> relatively recent machine.
Or a properly written desktop, or a thin clien
On Tue, 31 Mar 2009 14:43:55 -0400
Gregory Haskins wrote:
> The ioapic code currently privately manages the mapping between irq
> and vector. This results in some layering violations as the support
> for certain MSI operations need this info. As a result, the MSI
> code itself was moved to the
> Why? Do you see a guest filling all of memory with 'mov ss' and
> expecting to break out of it via an interrupt?
Well I did try mapping a page of move ss all through memory on real
hardware long ago and seeing what happened on a 386 in real mode with
DOSEMU. I was disappointed ;)
--
To unsubs
The minor number you are using already belongs to another project.
10,234 is free but it would be good to know what device naming is
proposed. I imagine other folks would like to know why you aren't using
sysfs or similar or extending /dev/kvm ?
Alan
--
To unsubscribe from this list: send the lin
> So it's good enough to be in Fedora/RHEL but not good enough to be in
> upstream
> glibc? How is that possible? Isnt that a double standard?
Yes its a double standard
Glibc has a higher standard than Fedora/RHEL.
Just like the Ubuntu kernel ships various ugly unfit for upstream kernel
driver
64bit Intel host system
Fedora host environment
32bit guest built with CPU i686 and no PAE support
This now momentarily flickers up something then reboots back to the BIOS.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Mo
> You have implemented second one, but seems it already was patented
> http://www.google.com/patents?vid=USPAT6789156
> I'm not a lawyer but IMHO we have direct conflict here.
> >From other point of view they have patented the WEEL, but at least we
> have to know about this.
Its an old idea and ap
> + r = !memcmp(old_digest, sha1_item->sha1val, SHA1_DIGEST_SIZE);
> + mutex_unlock(&sha1_lock);
> + if (r) {
> + char *old_addr, *new_addr;
> + old_addr = kmap_atomic(oldpage, KM_USER0);
> + new_addr = kmap_atomic(newpage, KM_USER1);
> +
On Tue, 2 Dec 2008 10:07:24 -0800
Chris Wright <[EMAIL PROTECTED]> wrote:
> * Alan Cox ([EMAIL PROTECTED]) wrote:
> > > + r = !memcmp(old_digest, sha1_item->sha1val, SHA1_DIGEST_SIZE);
> > > + mutex_unlock(&sha1_lock);
> > > + if (r)
On Tue, 2 Dec 2008 13:24:11 -0800
Chris Wright <[EMAIL PROTECTED]> wrote:
> * Alan Cox ([EMAIL PROTECTED]) wrote:
> > On Tue, 2 Dec 2008 10:07:24 -0800
> > Chris Wright <[EMAIL PROTECTED]> wrote:
> > > * Alan Cox ([EMAIL PROTECTED]) wrote:
> > >
> > Taken off list
>
> Hmmm, list would like to know :-).
That would be my choice too but unfortunately I can't do that
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.ht
On Tue, 17 Jun 2008 15:32:34 +0200
Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> * Anthony Liguori <[EMAIL PROTECTED]> [2008-06-17 08:16]:
> > VMware is a binary kernel module that's out of kernel. KVM is not
> > misbehaving and the fact that VMware breaks when the KVM module is
> > loaded isn't
26 matches
Mail list logo
