Am 05.09.2012 22:46, schrieb Anthony Liguori:
What do we do when the FSF comes out with the GPLv4 and relicenses again
in an incompatible fashion? Do we do this exercise every couple of
years?
That's exactly why I suggested GPLv2+ because it was supposed to be a
preparation for the future.
On Thu, Sep 6, 2012 at 3:42 AM, Alexander Graf ag...@suse.de wrote:
On 05.09.2012, at 15:38, Blue Swirl wrote:
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86 assembly is
no fun.
We can try linking to a disassembler library. I use udis86 to
disassemble instructions in kvm tracepoints
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86 assembly is
no fun.
We can try linking to a disassembler library.
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86
On 08.09.2012, at 12:16, Blue Swirl blauwir...@gmail.com wrote:
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity a...@redhat.com wrote:
On 09/05/2012 10:04 PM,
On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 12:16, Blue Swirl blauwir...@gmail.com wrote:
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 10:06, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Sep 6, 2012 at
On 08.09.2012, at 14:30, Blue Swirl blauwir...@gmail.com wrote:
On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012, at 12:16, Blue Swirl blauwir...@gmail.com wrote:
On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf ag...@suse.de wrote:
On 08.09.2012,
On 09/05/2012 10:04 PM, Blue Swirl wrote:
Reinventing a disassembler for ever growing x86 assembly is
no fun.
We can try linking to a disassembler library. I use udis86 to
disassemble instructions in kvm tracepoints
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where we've
asked folks to fix the license to comply with what I thought was our new
policy (it does not even contain a
On Wed, Sep 05, 2012 at 06:26:54PM +0300, Avi Kivity wrote:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where we've
asked folks to fix the license to comply
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where we've
asked folks to fix the license to comply with what I thought was our new
On 09/05/2012 06:41 PM, Anthony Liguori wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where we've
asked folks to fix the
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any different from a patch by IBM or Samsung where
On Tue, Sep 4, 2012 at 9:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 04, 2012 at 07:27:32PM +, Blue Swirl wrote:
On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity a...@redhat.com wrote:
On 09/03/2012 10:32 PM, Blue Swirl wrote:
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way this is being submitted I don't see why we should treat
Jan's patch any
On 09/05/2012 01:04 PM, Blue Swirl wrote:
I don't mind GPLv2+, if people want to share code from QEMU in GPLv3
projects, GPLv2+ enables that.
The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that
QEMU could share code from GPLv3 projects, specifically latest
binutils.
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00 AM, Anthony Liguori wrote:
Why? The way
On Wed, Sep 5, 2012 at 7:24 PM, Eric Blake ebl...@redhat.com wrote:
On 09/05/2012 01:04 PM, Blue Swirl wrote:
I don't mind GPLv2+, if people want to share code from QEMU in GPLv3
projects, GPLv2+ enables that.
The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that
QEMU could
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 12:00
On 05.09.2012, at 15:38, Blue Swirl wrote:
On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Avi Kivity a...@redhat.com writes:
On 09/05/2012
On 09/03/2012 10:32 PM, Blue Swirl wrote:
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems that might
conceivably become trivial problems some day. Especially when
On Tue, Sep 4, 2012 at 8:32 AM, Avi Kivity a...@redhat.com wrote:
On 09/03/2012 10:32 PM, Blue Swirl wrote:
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems that
Andreas Färber afaer...@suse.de writes:
Am 28.08.2012 14:57, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
On 08/29/2012 11:49 AM, Peter Maydell wrote:
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more specific name than pci-assign,
which implies that it is (a)
On 08/28/2012 03:30 AM, Jan Kiszka wrote:
Maybe add case 8: and default: with abort(), also below.
PIO is never 8 bytes long, the generic layer protects us.
Note: eventually the pio space will be mapped directly to mmio (instead
of being bounced via cpu_inb() in the bridge's mmio handler),
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems that might
conceivably become trivial problems some day. Especially when there's
no automated help with the avoiding.
-Wpointer-arith
--
error compiling committee.c: too many
On Mon, Sep 3, 2012 at 4:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/29/2012 11:27 AM, Markus Armbruster wrote:
I don't see a point in making contributors avoid non-problems that might
conceivably become trivial problems some day. Especially when there's
no automated help with the
On Mon, 2012-09-03 at 18:59 +0300, Avi Kivity wrote:
On 08/29/2012 11:49 AM, Peter Maydell wrote:
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more
On Tue, Aug 28, 2012 at 9:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin
Anthony Liguori anth...@codemonkey.ws writes:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
On 27 August 2012 13:15, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-27 14:07, Andreas Färber wrote:
Am I correct to understand we compile this only for i386 / x86_64?
This is correct.
Did we ever make a decision about whether architecture
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more specific name than pci-assign,
which implies that it is (a) ok for any PCI system and
(b) not something
On 2012-08-29 10:49, Peter Maydell wrote:
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more specific name than pci-assign,
which implies that it is (a) ok
Am 28.08.2012 14:57, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to
Andreas Färber afaer...@suse.de writes:
Am 28.08.2012 14:57, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
On Tue, 28 Aug 2012, Anthony Liguori wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael
On 27 August 2012 13:15, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-27 14:07, Andreas Färber wrote:
Am I correct to understand we compile this only for i386 / x86_64?
This is correct.
Did we ever make a decision about whether architecture specific
KVM devices should all live in
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for several years and is supported by libvirt as
On 2012-08-27 14:07, Andreas Färber wrote:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for
On Mon, Aug 27, 2012 at 06:56:38PM +, Blue Swirl wrote:
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
Why not?
We require gcc and
On Mon, Aug 27, 2012 at 7:01 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 06:56:38PM +, Blue Swirl wrote:
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Hi Blue,
thanks for the review. I addressed most of them, the others a commented
below.
On 2012-08-27 20:56, Blue Swirl wrote:
+typedef struct AssignedDevice {
+PCIDevice dev;
+PCIHostDeviceAddress host;
+uint32_t dev_id;
+uint32_t features;
+int intpin;
+
51 matches
Mail list logo
