On 11/29/2010 08:23 PM, Juan Quintela wrote:
Anthony Liguori wrote:
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
cheking each 64 pages is a random magic number as good as any other.
We don't want to test too many times, but on the other hand,
qemu_get_clock_ns()
On 11/29/2010 08:09 PM, Juan Quintela wrote:
Anthony Liguori wrote:
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
TLB handling is only used in TCG mode. It is very costly for guests with lots
of memory ad lots of CPU's.
Signed-off-by: Juan Quintela
Signed-off-by
On 11/24/2010 04:52 AM, Juan Quintela wrote:
"Michael S. Tsirkin" wrote:
On Wed, Nov 24, 2010 at 12:02:59AM +0100, Juan Quintela wrote:
From: Juan Quintela
diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..a728316 100644
--- a/buffered_file.h
+++ b/buffered_f
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
Calculate the number of dirty pages takes a lot on hosts with lots
of memory. Just maintain how many pages are dirty. Only sync bitmaps
if number is small enough.
There needs to be numbers that justify this as part of the c
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
cheking each 64 pages is a random magic number as good as any other.
We don't want to test too many times, but on the other hand,
qemu_get_clock_ns() is not so expensive either.
Signed-off-by: Juan Quintela
Signed-off-by: Juan Qui
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
Why?
Regards,
Anthony Liguori
---
arch_init.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 9e9
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
It returns a counter of things, not a ram address.
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
arch_init.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch_init.c b/arch_init.c
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
arch_init.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch_in
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
TLB handling is only used in TCG mode. It is very costly for guests with lots
of memory ad lots of CPU's.
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
exec.c |3 +++
1 files changed, 3 insertions(+), 0 del
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela
Once there, print all sections that take more than 100ms to migrate.
buffered file runs a timer at that 100ms interval.
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
savevm.c | 48 ++
On 11/23/2010 05:02 PM, Juan Quintela wrote:
From: Juan Quintela
This time is each time that buffered_file ticks happen
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
buffered_file.c |6 --
buffered_file.h |2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
d
On 11/23/2010 05:02 PM, Juan Quintela wrote:
From: Juan Quintela
When printing debug information for migration, print total time spent.
Signed-off-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --gi
On Thu, Nov 25, 2010 at 03:06:48PM +0900, Yoshiaki Tamura wrote:
> event-tap controls when to start FT transaction, and provides proxy
> functions to called from net/block devices. While FT transaction, it
> queues up net/block requests, and flush them when the transaction gets
> completed.
>
> S
On Mon, 2010-11-29 at 14:14 -0600, Anthony Liguori wrote:
> On 11/29/2010 01:58 PM, Alexander Graf wrote:
> > On 29.11.2010, at 20:29, Anthony Liguori wrote:
> >
> >
> >> Is 2 just right?
> >>
> > I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user?
> > Or 1 person
On Mon, Nov 29, 2010 at 02:02:20PM -0600, Anthony Liguori wrote:
> Savannah is down (and has been for two days) due to an intrusion that's
> still being investigated. There is not ETA for when service will be
> restored.
>
> I'd like to propose that we that we use this as an opportunity to move
Hi,
As most are probably aware, Savannah is experiencing an unexpected
downtime. I don't have a lot of details other than the fact that there
is not currently an ETA for when service will be restored.
In the interim, I've updated the wiki to make the latest release
download point to qemu.or
---
libcaccard/Makefile |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/libcaccard/Makefile b/libcaccard/Makefile
index a339af1..c4ea70a 100644
--- a/libcaccard/Makefile
+++ b/libcaccard/Makefile
@@ -3,15 +3,10 @@ include ../config-host.mak
include ../config-all-dev
Because of the hugeness of some patches (libcaccard) in the series, I'm just
sending this small patch that doesn't affect any of the code accept in removing
the -fPIC flag from the libcaccard objects. It's one of the things Blue Swirl
requested I remove which I forgot. It's to be applied after v8
On Mon, Nov 29, 2010 at 08:04:42PM +, Peter Maydell wrote:
> On 29 November 2010 19:54, Nathan Froyd wrote:
> > On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> >> (b) add to and extend the softfloat API whenever you have some
> >> floating-point related thing it doesn't curren
On 11/29/2010 01:58 PM, Alexander Graf wrote:
On 29.11.2010, at 20:29, Anthony Liguori wrote:
Is 2 just right?
I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1
person who knows his way around the area + 1 more?
+ 1 user? cute :-)
2 Acks seems l
On 29 November 2010 19:54, Nathan Froyd wrote:
> On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
>> (b) add to and extend the softfloat API whenever you have some
>> floating-point related thing it doesn't currently support
>
> I think this is the best approach whenever possible. I
Savannah is down (and has been for two days) due to an intrusion that's
still being investigated. There is not ETA for when service will be
restored.
I'd like to propose that we that we use this as an opportunity to move
the main integration tree from Savannah to git.qemu.org. Once Savannah
On 29.11.2010, at 20:29, Anthony Liguori wrote:
> On 11/29/2010 12:10 PM, Alexander Graf wrote:
>> On 29.11.2010, at 18:42, Anthony Liguori wrote:
>>
>>
>>> Hi,
>>>
>>> 0.13 was a mess of a release (largely due to my lack of time) and I'd like
>>> to get us back onto a predictable schedule.
On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> On 29 November 2010 17:49, Nathan Froyd wrote:
> > On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
> > As with other NaN-handling patches, I don't think the bit-twiddling here
> > is a good idea. Having a float*_maybe
On Mon, 2010-11-29 at 11:02 +0100, Kevin Wolf wrote:
> Am 29.11.2010 09:59, schrieb Kevin Wolf:
> > Am 27.11.2010 08:12, schrieb Stefan Hajnoczi:
> >> On Fri, Nov 26, 2010 at 9:59 PM, Christian Brunner
> >> wrote:
> >>> Thanks for the review. What am I supposed to do now?
> >>
> >> Kevin is the bl
On 11/29/2010 12:10 PM, Alexander Graf wrote:
On 29.11.2010, at 18:42, Anthony Liguori wrote:
Hi,
0.13 was a mess of a release (largely due to my lack of time) and I'd like to
get us back onto a predictable schedule.
Here's what I propose:
12/6 - fork off stable-0.14 tree; simultaneousl
On 29 November 2010 17:49, Nathan Froyd wrote:
> On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
>> + /* ARM requires that S<->D conversion of any kind of NaN generates
>> + * a quiet NaN by forcing the most significant frac bit to 1.
>> + */
>> + if (float64_is_signal
On Wed, Nov 24, 2010 at 03:20:06PM +, Peter Maydell wrote:
> Restore the VFP registers from the ucontext on return from a signal
> handler in linux-user mode. This means that signal handlers cannot
> accidentally corrupt the interrupted code's VFP state, and allows
> them to deliberately modify
On Wed, Nov 24, 2010 at 03:20:06PM +, Peter Maydell wrote:
> Restore the VFP registers from the ucontext on return from a signal
> handler in linux-user mode. This means that signal handlers cannot
> accidentally corrupt the interrupted code's VFP state, and allows
> them to deliberately modify
On Wed, Nov 24, 2010 at 03:20:05PM +, Peter Maydell wrote:
> For ARM linux-user mode signal handlers, fill in the ucontext with
> VFP register contents in the same way that the kernel does. We only
> do this for v2 format sigframe (2.6.12 and above); this is actually
> bug-for-bug compatible wi
Add an option to specify the host IP to send multicast packets from when
using a multicast socket for networking. The option takes an IP address
and sets the IP_MULTICAST_IF socket option, which causes the packets to
use that IP's interface as an egress.
This is useful if the host machine has seve
On Wed, Nov 24, 2010 at 03:20:04PM +, Peter Maydell wrote:
> Expose the vfp_get_fpscr() and vfp_set_fpscr() functions to C
> code as well as generated code, so we can use them to read and
> write the FPSCR when saving and restoring VFP registers across
> signal handlers in linux-user mode.
>
>
On Wed, Nov 24, 2010 at 03:20:03PM +, Peter Maydell wrote:
> The padding in the target_ucontext_v2 is defined by the size of
> the target's sigset_t type, not the host's. (This bug only causes
> problems when we start using the uc_regspace[] array to expose
> VFP registers to userspace signal h
On Mon, 29 Nov 2010, Alexander Graf wrote:
>
> On 29.11.2010, at 17:06, Anthony PERARD wrote:
>
> > On Mon, 29 Nov 2010, Alexander Graf wrote:
> >
> >>
> >> On 29.11.2010, at 16:10, Anthony PERARD wrote:
> >>
> >>> On Mon, 29 Nov 2010, Alexander Graf wrote:
> >>>
>
> On 23.11.2010, at 20
On Mon, 29 Nov 2010, Alexander Graf wrote:
>
> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>
> > From: Anthony PERARD
> >
> > With MapCache, we can handle a 64b target, even with a 32b host/qemu.
> > So, we need to have target_phys_addr_t to 64bits.
> >
> > Signed-off-by: Anthony PE
On Tue, Nov 23, 2010 at 06:53:50PM +, Peter Maydell wrote:
> Use the softfloat conversion routines for conversion to 16 bit
> integers, because just casting to a 16 bit type truncates the
> value rather than saturating it at 16-bit MAXINT/MININT.
>
> Signed-off-by: Peter Maydell
Reviewed-by:
On Tue, Nov 23, 2010 at 06:53:49PM +, Peter Maydell wrote:
> The ARM architecture needs float/double to 16 bit integer conversions.
> (The 32 bit versions aren't sufficient because of the requirement
> to saturate at 16 bit MAXINT/MININT and to get the exception bits right.)
>
> Signed-off-by:
On Tue, Nov 23, 2010 at 06:53:40PM +, Peter Maydell wrote:
> From: Johan Bengtsson
>
> The PKHxx instructions were not recognized by the thumb2 decoder. The
> solution provided in this changeset is identical to the arm-mode
> implementation.
>
> Signed-off-by: Johan Bengtsson
> Signed-off-b
Am 29.11.2010 15:42, schrieb Anthony Liguori:
Does anyone know of a tool that convert texi to wiki syntax or know
enough about texi parsing that something could be rigged up?
Even if it takes a couple steps, like texi2xml, then xml->wiki, that
would be workable. I'm willing to do some leg wor
On Tue, Nov 23, 2010 at 06:53:42PM +, Peter Maydell wrote:
> From: Adam Lackorzynski
>
> Refine check on bkpt so that smc and undefined instruction encodings are
> handled as an undefined instruction and trap.
>
> Signed-off-by: Adam Lackorzynski
> Signed-off-by: Peter Maydell
Reviewed-by
On Tue, Nov 23, 2010 at 06:53:44PM +, Peter Maydell wrote:
> Fix errors in the decoding of the Neon forms of fixed-point VCVT:
> * fixed-point VCVT is op 14 and 15, not 15 and 16
> * the fbits immediate field was being misinterpreted
> * the sense of the to_fixed bit was inverted
>
> Signed
On 29.11.2010, at 18:42, Anthony Liguori wrote:
> Hi,
>
> 0.13 was a mess of a release (largely due to my lack of time) and I'd like to
> get us back onto a predictable schedule.
>
> Here's what I propose:
>
> 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
>
> For t
On 29.11.2010, at 18:49, Anthony Liguori wrote:
> On 11/29/2010 11:37 AM, Attila Sukosd wrote:
>>
>> Hi,
>>
>> I guess it should be abstract enough to support multiple back-ends, be it a
>> kernel driver or through libusb?
>
> Is this something that should just live in libusb?
>
> If what li
On 29.11.2010, at 17:06, Anthony PERARD wrote:
> On Mon, 29 Nov 2010, Alexander Graf wrote:
>
>>
>> On 29.11.2010, at 16:10, Anthony PERARD wrote:
>>
>>> On Mon, 29 Nov 2010, Alexander Graf wrote:
>>>
On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
> From: Antho
On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
> From: Anthony PERARD
>
> With MapCache, we can handle a 64b target, even with a 32b host/qemu.
> So, we need to have target_phys_addr_t to 64bits.
>
> Signed-off-by: Anthony PERARD
> ---
> configure |3 +++
> 1 files changed, 3 in
On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
> The ARM ARM defines that if the input to a single<->double conversion
> is a NaN then the output is always forced to be a quiet NaN by setting
> the most significant bit of the fraction part.
>
> Signed-off-by: Peter Maydell
>
> @@
On 11/29/2010 11:37 AM, Attila Sukosd wrote:
Hi,
I guess it should be abstract enough to support multiple back-ends, be
it a kernel driver or through libusb?
Is this something that should just live in libusb?
If what libusb presented QEMU was actually implemented as USB-over-IP,
QEMU wouldn
Hi,
0.13 was a mess of a release (largely due to my lack of time) and I'd
like to get us back onto a predictable schedule.
Here's what I propose:
12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
For the stable-0.14 tree, I'd like to have Justin be in charge of
collec
Hi,
I guess it should be abstract enough to support multiple back-ends, be it a
kernel driver or through libusb?
Rgrds,
Attila
2010/11/29 Gerd Hoffmann
> Hi,
>
>
> I'm note sure about what I will say, but will a kernel approach
>> handle specific disconnection/reconnection of devices, tha
On 11/29/2010 11:18 AM, Paul Brook wrote:
On 11/29/2010 10:53 AM, Paul Brook wrote:
Is this a fair summary: any device that supports live migration workw
under Kemari?
It might be fair summary but practically we barely have live migration
working w/o Kemari. In addition, last
>>> The idea here is that a usb device connected to machine a, will be
>>> available for use by the guest os running on host b (machine b).
>>>
>>> I'm working on this because it is something which we want / need
>>> for spice. I'm wondering if there is interest in this outside
>>> of spice ?
>>>
> On 11/29/2010 10:53 AM, Paul Brook wrote:
> >>> Is this a fair summary: any device that supports live migration workw
> >>> under Kemari?
> >>
> >> It might be fair summary but practically we barely have live migration
> >> working w/o Kemari. In addition, last I checked Kemari needs additional
>Hi,
>
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I
On Tue, Nov 23, 2010 at 06:53:48PM +, Peter Maydell wrote:
> VCVT of 16 bit fixed point to float should ignore the top 16 bits
> of the source register. Cast to int16_t and friends rather than
> int16 -- the former is guaranteed exactly 16 bits wide where the
> latter is merely at least 16 bits
On Tue, Nov 23, 2010 at 06:53:41PM +, Peter Maydell wrote:
> From: Johan Bengtsson
>
> The thumb2 decoder contained a mixup between the bit controlling
> doubling and the bit controlling if the operation was an add or a sub.
>
> Signed-off-by: Johan Bengtsson
> Signed-off-by: Peter Maydell
On 11/29/2010 10:53 AM, Paul Brook wrote:
Is this a fair summary: any device that supports live migration workw
under Kemari?
It might be fair summary but practically we barely have live migration
working w/o Kemari. In addition, last I checked Kemari needs additional
hooks and it will b
On Mon, Nov 29, 2010 at 04:49:24PM +, Peter Maydell wrote:
> On 29 November 2010 16:38, Nathan Froyd wrote:
> > Why not just use:
> >
> > static int float32_is_any_nan(float32 x)
> > {
> > return float32_is_nan(x) || float32_is_signaling_nan(x);
> > }
> >
> > and likewise for the 64-bit case?
> > Is this a fair summary: any device that supports live migration workw
> > under Kemari?
>
> It might be fair summary but practically we barely have live migration
> working w/o Kemari. In addition, last I checked Kemari needs additional
> hooks and it will be too hard to keep that out of tree
On 29 November 2010 16:38, Nathan Froyd wrote:
>> +static int float32_is_any_nan(float32 x)
>> +{
>> + return ((float32_val(x) & ~(1 << 31)) > 0x7f80UL);
>> +}
>> +
>> +static int float64_is_any_nan(float64 x)
>> +{
>> + return ((float64_val(x) & ~(1ULL << 63)) > 0x7ff0ULL);
On 11/29/2010 06:23 PM, Stefan Hajnoczi wrote:
On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura
wrote:
2010/11/29 Paul Brook:
If devices incorrectly claim support for live migration, then that should
also be fixed, either by removing the broken code or by making it work.
I totally agree wit
On Tue, Nov 23, 2010 at 06:53:46PM +, Peter Maydell wrote:
> The ARM architecture mandates that converting a NaN value to
> integer gives zero (if Invalid Operation FP exceptions are
> not being trapped). This isn't the behaviour of the SoftFloat
> library, so NaNs must be special-cased.
>
> +
Hi,
I'm note sure about what I will say, but will a kernel approach
handle specific disconnection/reconnection of devices, that libusb
cannot?
Don't know, didn't investigate (yet) what libusb can do and what it can't.
cheers,
Gerd
On Tue, Nov 23, 2010 at 06:53:45PM +, Peter Maydell wrote:
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
Switch the usb bluetooth driver over to the
new descriptor infrastructure.
Signed-off-by: Gerd Hoffmann
---
hw/usb-bt.c | 470 +--
1 files changed, 200 insertions(+), 270 deletions(-)
diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index 56d1a6c..
Switch the usb storage driver over to the
new descriptor infrastructure.
Signed-off-by: Gerd Hoffmann
---
hw/usb-msd.c | 164 +
1 files changed, 61 insertions(+), 103 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 0a95d8d..b0
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I don't recall
On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura
wrote:
> 2010/11/29 Paul Brook :
>>> > If devices incorrectly claim support for live migration, then that should
>>> > also be fixed, either by removing the broken code or by making it work.
>>>
>>> I totally agree with you.
>>>
>>> > AFAICT your cu
This patch allows to set usb descriptor strings per device instance.
Signed-off-by: Gerd Hoffmann
---
hw/usb-bus.c |1 +
hw/usb-desc.c | 52
hw/usb-desc.h |4 +++-
hw/usb.h |9 +
4 files changed, 57 insertions(+), 9
On Mon, 29 Nov 2010, Alexander Graf wrote:
>
> On 29.11.2010, at 16:10, Anthony PERARD wrote:
>
> > On Mon, 29 Nov 2010, Alexander Graf wrote:
> >
> >>
> >> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
> >>
> >>> From: Anthony PERARD
> >>>
> >>> Hi all,
> >>>
> >>> Here is the V7 of
This patch adds fields to the USBDevice struct for the current
speed (hard-wired to full speed for now) and current device
configuration. Also a init function is added which inializes
these fields. This allows USB_REQ_{GET,SET}_CONFIGURATION
handling to be moved to common code.
For most drivers
USB_REQ_SET_ADDRESS handling is identical in *all* emulated devices.
Move it to common code.
Signed-off-by: Gerd Hoffmann
---
hw/usb-bt.c |4
hw/usb-desc.c |4
hw/usb-hid.c|4
hw/usb-hub.c|4
hw/usb-msd.c|4
hw/usb-net.c|5 --
This patch adds hw/usb-desc.[ch] files. They carry data structures
for various usb descriptors and helper functions to generate usb
packets from the structures.
The intention is to have a internal representation of the device
desription which is more usable than the current char array blobs,
so w
Switch the usb network driver over to the
new descriptor infrastructure.
Signed-off-by: Gerd Hoffmann
---
hw/usb-net.c | 450 +++---
1 files changed, 207 insertions(+), 243 deletions(-)
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 54d23fb..
Switch the usb hub driver over to the
new descriptor infrastructure.
It also removes the nr_ports variable and MAX_PORTS define and
introduces a NUM_PORTS define instead. The numver of ports was
(and still is) fixed at 8 anyway.
Signed-off-by: Gerd Hoffmann
---
hw/usb-hub.c | 141
If a serial number is present for the drive fill it into the usb
serialnumber string descriptor.
Signed-off-by: Gerd Hoffmann
---
hw/usb-msd.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index b049122..7b6a0d7 100644
--- a/hw/usb-msd.
Switch the usb hid drivers (keyboard, mouse, tablet) over to the
new descriptor infrastructure.
Signed-off-by: Gerd Hoffmann
---
hw/usb-hid.c | 445 ++---
1 files changed, 203 insertions(+), 242 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb
Switch the usb serial drivers (serial, braille) over to the
new descriptor infrastructure.
Note that this removes the freely configurable vendor and product id
properties. I think the only reason this was configurable is that the
only difference between the serial and the braille device is the
ve
Switch the usb wavom driver over to the
new descriptor infrastructure.
Signed-off-by: Gerd Hoffmann
---
hw/usb-wacom.c | 175 +++-
1 files changed, 71 insertions(+), 104 deletions(-)
diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 47f26cd.
Hi,
This patch series is the start for an overhaul of the usb descriptor
handling for emulated usb devices. Instead of storing the device
desriptors in blobs (aka char arrays) they are stored in structs,
which makes it alot easier to work with them. This in turn allows
to move common device ma
> >> Sorry, I didn't get what you're trying to tell me. My plan would
> >> be to initially start from a subset of devices, and gradually
> >> grow the number of devices that Kemari works with. While this
> >> process, it'll include what you said above, file a but and/or fix
> >> the code. Am I m
On 29 November 2010 15:45, Prasad Joshi wrote:
> I tried to emulate few other boards as well. IMHO, versatilepb
> supports more than 256M RAM, I guess it supports upto 512MB. But it
> too fails
No, 'versatilepb' also supports only 256MB of RAM, for the
same reason (system registers starting at 0x
Hi,
Not me at the moment, but unless you tunnel it inside another
protocol, you'd really want to look at the existing USB-over-IP
protocols instead of reinventing the wheel:
http://usbip.sourceforge.net/ (some support in Linux already IIRC)
(and there are others which I don't recall)
Doesn't
On Mon, Nov 29, 2010 at 3:13 PM, Peter Maydell wrote:
> On 29 November 2010 14:37, Prasad Joshi wrote:
>> I am running QEMU Arm emulation on x86_64 machine. I downloaded the
>> arm-test kernel and the initrd image available on QEMU download site.
>>
>> When I run the qemu-system-arm with the memo
On 29.11.2010, at 16:10, Anthony PERARD wrote:
> On Mon, 29 Nov 2010, Alexander Graf wrote:
>
>>
>> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>>
>>> From: Anthony PERARD
>>>
>>> Hi all,
>>>
>>> Here is the V7 of the patch series that adds Xen device model support in
>>> QEM
Avoid sending out packets, and modifying
device state, when VM is stopped.
Add assert statements to verify this does not happen.
Avoid scheduling bh when vhost-net is started.
Stop bh when driver disabled bus mastering
(we must not access memory after this).
Signed-off-by: Michael S. Tsirkin
-
On Mon, Nov 29, 2010 at 02:58:57PM +0100, Alexander Graf wrote:
> > Nathan Froyd a écrit :
> >> I'm sorry, what are the "both talks" you refer to above? Are you
> >> proposing an additional talk alongside your (Frédéric's) existing talk?
> >
> > No! I am very happy that you take over the introdu
On 29 November 2010 14:37, Prasad Joshi wrote:
> I am running QEMU Arm emulation on x86_64 machine. I downloaded the
> arm-test kernel and the initrd image available on QEMU download site.
>
> When I run the qemu-system-arm with the memory less than or equal to
> 256M everything works fine.
> pra.
On Mon, 29 Nov 2010, Alexander Graf wrote:
>
> On 23.11.2010, at 20:51, anthony.per...@citrix.com wrote:
>
> > From: Anthony PERARD
> >
> > Hi all,
> >
> > Here is the V7 of the patch series that adds Xen device model support in
> > QEMU.
> >
> > The change made on it since the v6:
> > - I intr
@earl,
thanks for finding the specific patch!
--
virsh save is very slow
https://bugs.launchpad.net/bugs/524447
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in libvirt virtualization API: Unknown
Status in QEMU: Invalid
Statu
Frederick,
please let me know if you can confirm that this patch fixes it for you. If you
need
me to set up a ppa with that patch, please let me know.
--
virsh save is very slow
https://bugs.launchpad.net/bugs/524447
You received this bug notification because you are a member of qemu-
devel-ml
Paul Brook writes:
>> > Likewise requiring separate tracing hooks be added to the existing
>> > decoders is extremely unlikely to be a feasible long-term
>> > solution.
>>
>> You mean having to modify each "translate.c"? The worst event to handle
>> is instruction fetch on x86.
> Instruction fet
2010/11/29 Paul Brook :
>> > If devices incorrectly claim support for live migration, then that should
>> > also be fixed, either by removing the broken code or by making it work.
>>
>> I totally agree with you.
>>
>> > AFAICT your current proposal is just feeding back the results of some
>> > fair
On Mon, Nov 29, 2010 at 08:34:28AM -0600, Anthony Liguori wrote:
> On 11/28/2010 04:56 AM, Alexander Graf wrote:
>> On 28.11.2010, at 01:17, Nathan Froyd wrote:
>>> We (CodeSourcery) are very interested in Windows host support. (We
>>> distribute QEMU with our commerical development products for
>
> > If devices incorrectly claim support for live migration, then that should
> > also be fixed, either by removing the broken code or by making it work.
>
> I totally agree with you.
>
> > AFAICT your current proposal is just feeding back the results of some
> > fairly specific QA testing. I'd
2010/11/29 Paul Brook :
>> >> To answer Stefan's question, there shouldn't be any requirement
>> >> for a device, but must be tested with Kemari. If it doesn't work
>> >> correctly, the problems must be fixed before adding to the list.
>> >
>> > What exactly are the problems? Is this a device bus
Hello All,
I am running QEMU Arm emulation on x86_64 machine. I downloaded the
arm-test kernel and the initrd image available on QEMU download site.
When I run the qemu-system-arm with the memory less than or equal to
256M everything works fine.
pra...@prasad-desktop:~/Downloads/arm-test$ qemu-sy
Does anyone know of a tool that convert texi to wiki syntax or know
enough about texi parsing that something could be rigged up?
Even if it takes a couple steps, like texi2xml, then xml->wiki, that
would be workable. I'm willing to do some leg work but I don't want to
write a texi parser from
On 11/28/2010 04:56 AM, Alexander Graf wrote:
On 28.11.2010, at 01:17, Nathan Froyd wrote:
On Fri, Nov 26, 2010 at 01:26:31AM +0100, François Revol wrote:
the people we are addressing and we would like to bring together is from the
QEMU emulation community.
We are interested in runn
>
> Hi All,
>
> Now that I have usb-1.1 passthrough / local redirection support
> working reliably (see my patch sets for this), I'm going to start
> working on doing usb redirection support over the network.
>
> The idea here is that a usb device connected to machine a, will be
> available for
On 29.11.2010, at 15:27, Jan Kiszka wrote:
> Am 29.11.2010 15:15, Alexander Graf wrote:
>>
>> On 29.11.2010, at 13:44, Jan Kiszka wrote:
>>
>>> Am 29.11.2010 13:40, Alexander Graf wrote:
On 29.11.2010, at 13:30, Jan Kiszka wrote:
> Am 29.11.2010 13:24, Alexander Graf wrote:
1 - 100 of 132 matches
Mail list logo
