On 12/05/2015 13:48, Fam Zheng wrote:
> This checks that the discard on mirror source that effectively zeroes
> data is also reflected by the data of target.
>
> Signed-off-by: Fam Zheng
> Reviewed-by: John Snow
> ---
> tests/qemu-iotests/131 | 59
> ++
On 14/05/2015 12:29, Wen Congyang wrote:
>
> If buf_size % granularity is not 0, mirror_free_init() will
> do dangerous things.
>
> Signed-off-by: Wen Congyang
> ---
> block/mirror.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/mirror.c b/block/mirror.c
> in
On 14 May 2015 at 11:31, Andrew Jones wrote:
> Forgot to (4): switch from setting userspace's mapping to
> device memory to normal, non-cacheable. Using device memory
> caused a problem that Alex Graf found, and Peter Maydell suggested
> using normal, non-cacheable instead.
Did you check that non
Am 14.05.2015 um 12:09 schrieb Paolo Bonzini:
>
>
> On 14/05/2015 12:07, Michael S. Tsirkin wrote:
>>> If you really want that, the hook should be in the virtio device class.
>>> Keying on the machine type is almost never the answer, at least upstream.
>>> Distros can always override it if they k
On Wed, May 13, 2015 at 01:31:54PM +0200, Andrew Jones wrote:
> When S1 and S2 memory attributes combine wrt to caching policy,
> non-cacheable types take precedence. If a guest maps a region as
> device memory, which KVM userspace is using to emulate the device
> using normal, cacheable memory, th
Fam Zheng writes:
> On Wed, 05/13 19:34, Alexander Yarygin wrote:
>> Paolo Bonzini writes:
>>
>> > On 13/05/2015 17:18, Alexander Yarygin wrote:
>> >> After the commit 9b536adc ("block: acquire AioContext in
>> >> bdrv_drain_all()") the aio_poll() function got called for every
>> >> BlockDriver
Building the QEMU tools fails if we #define DEBUG_BLOCK inside
block/raw-posix.c. Here instead of adding qemu-log.o in block-obj-y
so that DEBUG_BLOCK_PRINT can be used, we substitute the latter with
a simple DPRINTF() (that does not cause bit-rot).
Signed-off-by: Dimitris Aragiorgis
---
block/r
Get rid of several #ifdef DEBUG_FLOPPY and substitute them with
DPRINTF.
Signed-off-by: Dimitris Aragiorgis
---
block/raw-posix.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index ff7dc4d..82e522f 100644
---
Hi all,
These four patches make slight changes to the way QEMU handles SCSI
generic devices to fix a number of small problems.
I am sending them against the master branch, since I don't know if they
can be considered bugfixes.
Thanks,
dimara
v3 (rebased to current master):
* Avoid bit-rot in DP
During migration, QEMU uses fsync()/fdatasync() on the open file
descriptor for read-write block devices to flush data just before
stopping the VM.
However, fsync() on a scsi-generic device returns -EINVAL which
causes the migration to fail. This patch skips flushing data in case
of an SG device,
Instead of checking bs->sg use bdrv_is_sg() consistently throughout
the code.
Signed-off-by: Dimitris Aragiorgis
Reviewed-by: Paolo Bonzini
---
block.c |6 +++---
block/iscsi.c |2 +-
block/raw-posix.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --g
Hello Kevin,
* Kevin Wolf [2015-05-11 12:12:23 +0200]:
> Am 08.05.2015 um 19:47 hat Dimitris Aragiorgis geschrieben:
> > During migration, QEMU uses fsync()/fdatasync() on the open file
> > descriptor for read-write block devices to flush data just before
> > stopping the VM.
> >
> > However, f
Until now, an SG device was identified only by checking if its path
started with "/dev/sg". Then, hdev_open() set bs->sg accordingly.
This is very fragile, e.g. it fails with symlinks or relative paths.
We should rely on the actual properties of the device instead of the
specified file path.
Test
On Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
> Provide a method to change normal, cacheable memory to non-cacheable.
> KVM will make use of this to keep emulated device memory regions
> coherent with the guest.
>
> Signed-off-by: Andrew Jones
Reviewed-by: Christoffer Dall
But
On 05/14/15 12:30, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
>> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
>> needed by ARM. This flag informs KVM that the given memory region
>> is typically mapped by the guest as non-cacheable. KVM
On Wed, 13 May 2015, John Snow wrote:
> On 05/13/2015 02:15 PM, Stefano Stabellini wrote:
> > On Wed, 13 May 2015, Daniel P. Berrange wrote:
> >> On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote:
> >>> Do not emulate a floppy drive if no drives are supposed to be present.
> >>>
>
On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> On Wed, 13 May 2015, John Snow wrote:
> > On 05/13/2015 02:15 PM, Stefano Stabellini wrote:
> > > On Wed, 13 May 2015, Daniel P. Berrange wrote:
> > >> On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote:
> > >>> D
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: Yang Hongyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> ---
> docs/block-replication.txt | 179
> +
> 1 file changed, 179 insertions(+)
> cr
On Thu, 14 May 2015, Leon Alrae wrote:
> > I don't think we have. The specification is a bit unclear I must admit
> > and it also defines the details of vector load and store operations as
> > implementation dependent, so there's no further clarification.
>
> This is specified in "MIPS Archit
Bandan Das writes:
> When a command fails due to incorrect syntax or input,
> suggest using the "help" command to get more information
> about the command. This is only applicable for HMP.
>
> Before:
> (qemu) drive_add usb_flash_drive
> drive_add: string expected
> After:
> (qemu) drive_add usb_
On Thu, May 14, 2015 at 01:09:34PM +0200, Laszlo Ersek wrote:
> On 05/14/15 12:30, Christoffer Dall wrote:
> > On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
> >> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
> >> needed by ARM. This flag informs KVM that the given m
Ah well, I only have the "normal" PATH set, not library or include path.
But I managed to build qemu now by just building pixman separately.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1453436
Titl
On 14/05/2015 13:29, Christoffer Dall wrote:
> > (It's probably worth looking at the documentation in the first hunk too,
> > under the commit message.)
>
> Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
> not simply that MMIO regions are coherent?
Only until device assig
On Thu, May 14, 2015 at 01:31:03PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:29, Christoffer Dall wrote:
> > > (It's probably worth looking at the documentation in the first hunk too,
> > > under the commit message.)
> >
> > Why is this a hack/unintuitive? Is the semantics of the QEMU
On 14/05/2015 13:36, Christoffer Dall wrote:
> > > > (It's probably worth looking at the documentation in the first hunk too,
> > > > under the commit message.)
> > >
> > > Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
> > > not simply that MMIO regions are coherent?
> >
Hello.
Ternary/if/else >= python 2.5 (I use the same coding as in
scripts/qmp/qemu-ga-client).
"import json" >= python 2.6 (scripts/qmp/qmp.py)
"import argparse" >= python 2.7 (scripts/analyze-migration.py,
scripts/vmstate-static-checker.py)
"import optparse" < python 2.7 (deprecated, scripts/q
On Thu, May 14, 2015 at 12:18:26PM +0100, Daniel P. Berrange wrote:
> On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> > On Wed, 13 May 2015, John Snow wrote:
> > > On 05/13/2015 02:15 PM, Stefano Stabellini wrote:
> > > > On Wed, 13 May 2015, Daniel P. Berrange wrote:
> > > >>
On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> I would be OK with a new property too, as we could set it from
> libxl or libvirt. Anybody would be happy to pick this one up or should I
> do it?
Pls go ahead, I can merge it in the pc tree.
--
MST
On 14/05/2015 13:41, Martin Cerveny wrote:
> Hello.
>
> Ternary/if/else >= python 2.5 (I use the same coding as in
> scripts/qmp/qemu-ga-client).
Oh, that's old. Shows my knowledge of Python.
Then your patch is okay---thanks for enduring with me. :)
Paolo
> "import json" >= python 2.6 (scri
On 14/05/2015 13:47, Michael S. Tsirkin wrote:
> > I would be OK with a new property too, as we could set it from
> > libxl or libvirt. Anybody would be happy to pick this one up or should I
> > do it?
>
> Pls go ahead, I can merge it in the pc tree.
Note that because of the "-drive if=none,id=f
On Thu, May 14, 2015 at 01:54:22PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:47, Michael S. Tsirkin wrote:
> > > I would be OK with a new property too, as we could set it from
> > > libxl or libvirt. Anybody would be happy to pick this one up or should I
> > > do it?
> >
> > Pls go ahead
On Thu, May 14, 2015 at 01:38:38PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:36, Christoffer Dall wrote:
> > > > > (It's probably worth looking at the documentation in the first hunk
> > > > > too,
> > > > > under the commit message.)
> > > >
> > > > Why is this a hack/unintuitive? Is
Hi Pavel,
Please see in-line.
Best regards,
S.P.
From: Pavel Fedin [p.fe...@samsung.com]
Sent: Wednesday, May 13, 2015 4:57 PM
To: Shlomo Pongratz; qemu-devel@nongnu.org
Subject: RE: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500
Hello!
"Daniel P. Berrange" writes:
> On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
>> On Wed, 13 May 2015, John Snow wrote:
>> > On 05/13/2015 02:15 PM, Stefano Stabellini wrote:
>> > > On Wed, 13 May 2015, Daniel P. Berrange wrote:
>> > >> On Wed, May 13, 2015 at 06:29:46PM +0100
On 13/05/2015 18:34, Alexander Yarygin wrote:
> Ah, right. We need second loop, something like this:
>
> @@ -2030,20 +2033,33 @@ void bdrv_drain(BlockDriverState *bs)
> void bdrv_drain_all(void)
> {
> /* Always run first iteration so any pending completion BHs run */
> -bool busy = tr
On 14/05/2015 14:00, Christoffer Dall wrote:
> So, getting back to my original question. Is the point then that UEFI
> must assume (from ACPI/DT) the cache-coherency properties of the PCI
> controller which exists in hardware on the system you're running on,
> even for the virtual PCI bus becaus
On 14/05/2015 14:02, Markus Armbruster wrote:
> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
> commonly don't have an FDC (depends on the Super I/O chip used).
>
> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt
> there's a real i440FX without an
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> This is the 4th version of COLO, here is only COLO frame part, include: VM
> checkpoint,
> failover, proxy API, block replication API, not include block replication.
> The block part has been sent by wencongyang:
> [RFC PATCH COLO v2 00/13]
On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 14:00, Christoffer Dall wrote:
> > So, getting back to my original question. Is the point then that UEFI
> > must assume (from ACPI/DT) the cache-coherency properties of the PCI
> > controller which exists in hard
On 14/05/2015 14:24, Christoffer Dall wrote:
> On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 14/05/2015 14:00, Christoffer Dall wrote:
>>> So, getting back to my original question. Is the point then that UEFI
>>> must assume (from ACPI/DT) the cache-coherency propert
On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 14:24, Christoffer Dall wrote:
> > On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/05/2015 14:00, Christoffer Dall wrote:
> >>> So, getting back to my original question. Is the
On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> Well, PCI BARs are generally MMIO resources, and hence should not be cached.
>
> As an optimization, OS drivers can mark them as cacheable or
> write-combining or something like that, but in general it's a safe
> default to leave them uncached---one
Paolo Bonzini writes:
> On 14/05/2015 14:02, Markus Armbruster wrote:
>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
>> commonly don't have an FDC (depends on the Super I/O chip used).
>>
>> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt
>> the
On Thu, May 14, 2015 at 02:45:30PM +0200, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
> > On 14/05/2015 14:02, Markus Armbruster wrote:
> >> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
> >> commonly don't have an FDC (depends on the Super I/O chip used).
> >>
Now that the two functions are identical, we only need one of them,
and we might as well give it a more descriptive name. Basically,
the function serves as the translation from a QAPI name into a
(portion of a) C identifier, without regards to whether it is a
variable or function name.
Signed-off
This series makes it possible to use downstream extensions
(such as __com.redhat_xyz) and temporary names (such as x-foo)
in every position possible in QAPI schemes, with added tests
that the generated code still compiles.
There's still some things we could do to the qapi generator,
such as normal
From: Markus Armbruster
Signed-off-by: Markus Armbruster
Signed-off-by: Eric Blake
---
scripts/qapi.py | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 1258f76..b917cad 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -961,6 +9
Enhance the testsuite to cover a downstream enum type and enum
string. Update the generator to mangle the enum name in the
appropriate places.
Signed-off-by: Eric Blake
---
v4: use type_name() instead of special-casing builtins in
generate_visit_list()
---
scripts/qapi-types.py
Enhance the testsuite to cover downstream events and commands.
Events worked without more tweaks, but commands needed a few final
updates in the generator to mangle names in the appropriate places.
In making those tweaks, it was easier to drop type_visitor() and
inline its actions instead.
Signed-
Enhance the testsuite to cover downstream alternates, including
whether the branch name or type is downstream. Update the
generator to mangle alternate names in the appropriate places.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
scripts/qapi-types.py | 7
Enhance the testsuite to cover downstream simple unions, including
when a union branch is a downstream name. Update the generator to
mangle the union names in the appropriate places.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
scripts/qapi-types.py | 2 +-
sc
Use of python's % operator to format strings is fine if there are
multiple strings or if there is integer formatting going on, but
when it is just abused for string concatenation, it looks nicer
to just use the + operator. This is particularly true when the
value being substituted is at the front
c_type() is designed to be called on both string names and on
array designations, so 'name' is a bit misleading because it
operates on more than strings. Also, no caller ever passes
an empty string. Finally, + notation is a bit nicer to read
than '%s' % value for string concatenation.
Signed-off
Enhance the testsuite to cover downstream structs, including struct
members and base structs. Update the generator to mangle the
struct names in the appropriate places.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
scripts/qapi-types.py | 4 ++--
scripts/qapi-
Enhance the testsuite to cover downstream flat unions, including
the base type, discriminator name and type, and branch name and
type. Update the generator to mangle the union names in the
appropriate places.
Signed-off-by: Eric Blake
Reviewed-by: Markus Armbruster
---
scripts/qapi-types.py
From: Markus Armbruster
Signed-off-by: Markus Armbruster
Signed-off-by: Eric Blake
---
scripts/qapi.py | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 3757a91..cc33355 100644
--- a/
From: Markus Armbruster
Signed-off-by: Markus Armbruster
Signed-off-by: Eric Blake
---
scripts/qapi.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index a4701ca..7330f7c 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@
On 14/05/2015 14:45, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 14/05/2015 14:02, Markus Armbruster wrote:
>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
>>> commonly don't have an FDC (depends on the Super I/O chip used).
>>>
>>> We may want to ke
From: Markus Armbruster
Signed-off-by: Markus Armbruster
Signed-off-by: Eric Blake
---
scripts/qapi-event.py | 5 ++---
scripts/qapi-types.py | 6 +++---
scripts/qapi-visit.py | 4 ++--
scripts/qapi.py | 6 +++---
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/scripts/q
From: Markus Armbruster
c_fun() maps '.' to '_', c_var() doesn't. Nothing prevents '.' in
QAPI names that get passed to c_var().
Which QAPI names get passed to c_fun(), to c_var(), or to both is not
obvious. Names of command parameters and struct type members get
passed to c_var().
c_var() st
On 2015/5/14 20:14, Dr. David Alan Gilbert wrote:
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
This is the 4th version of COLO, here is only COLO frame part, include: VM
checkpoint,
failover, proxy API, block replication API, not include block replication.
The block part has been sen
Continuing the string of cleanups for supporting downstream names
containing '.', this patch focuses on ensuring c_type() can
handle a downstream name. This patch alone does not fix the
places where generator output should be calling this function
but was open-coding things instead, but it gets us
From: Markus Armbruster
Missed in commit b0b5819.
Signed-off-by: Markus Armbruster
Signed-off-by: Eric Blake
---
scripts/qapi-types.py | 6 ++
scripts/qapi.py | 11 ---
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-type
On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> On 14 May 2015 at 11:31, Andrew Jones wrote:
> > Forgot to (4): switch from setting userspace's mapping to
> > device memory to normal, non-cacheable. Using device memory
> > caused a problem that Alex Graf found, and Peter Maydell s
On 05/14/2015 06:50 AM, Eric Blake wrote:
> This series makes it possible to use downstream extensions
> (such as __com.redhat_xyz) and temporary names (such as x-foo)
> in every position possible in QAPI schemes, with added tests
> that the generated code still compiles.
>
> There's still some th
On 14 May 2015 at 14:03, Andrew Jones wrote:
> On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
>> On 14 May 2015 at 11:31, Andrew Jones wrote:
>> > Forgot to (4): switch from setting userspace's mapping to
>> > device memory to normal, non-cacheable. Using device memory
>> > caused
On 14/05/2015 13:02, Dimitris Aragiorgis wrote:
> Also note that QEMU seems to flush the disk cache explicitly in
> case of iSCSI, using iscsi_synchronizecache10_task() from libiscsi
> inside iscsi_co_flush().
Right, QEMU does that if type is DISK only.
> Perhaps we can also extend this approac
Thursday, May 14, 2015, 2:53:17 PM, you wrote:
> On 14/05/2015 14:45, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 14/05/2015 14:02, Markus Armbruster wrote:
It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
commonly don't have an FDC (depends
On Thu, May 14, 2015 at 12:55:49PM +0200, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:54PM +0200, Andrew Jones wrote:
> > When S1 and S2 memory attributes combine wrt to caching policy,
> > non-cacheable types take precedence. If a guest maps a region as
> > device memory, which KVM use
On 05/14/15 15:00, Andrew Jones wrote:
> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
>> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
>>> Well, PCI BARs are generally MMIO resources, and hence should not be cached.
>>>
>>> As an optimization, OS drivers can mark them as cacheabl
On 05/14/15 15:11, Peter Maydell wrote:
> On 14 May 2015 at 14:03, Andrew Jones wrote:
>> On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
>>> On 14 May 2015 at 11:31, Andrew Jones wrote:
Forgot to (4): switch from setting userspace's mapping to
device memory to normal, no
On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote:
> On 14 May 2015 at 14:03, Andrew Jones wrote:
> > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> >> On 14 May 2015 at 11:31, Andrew Jones wrote:
> >> > Forgot to (4): switch from setting userspace's mapping to
> >>
On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> > Well, PCI BARs are generally MMIO resources, and hence should not be cached.
> >
> > As an optimization, OS drivers can mark them as cacheable or
> > write-combining or something like
On Wed, Aug 27, 2014 at 9:43 AM, Chris Friesen
wrote:
> On 08/25/2014 03:50 PM, Chris Friesen wrote:
>
>> I think I might have a glimmering of what's going on. Someone please
>> correct me if I get something wrong.
>>
>> I think that VIRTIO_PCI_QUEUE_MAX doesn't really mean anything with
>> respe
On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote:
>
> Thursday, May 14, 2015, 2:53:17 PM, you wrote:
>
>
>
> > On 14/05/2015 14:45, Markus Armbruster wrote:
> >> Paolo Bonzini writes:
> >>
> >>> On 14/05/2015 14:02, Markus Armbruster wrote:
> It should certainly be of
On Thu, 05/14 11:36, Paolo Bonzini wrote:
> On 14/05/2015 06:39, Fam Zheng wrote:
> > On Thu, 05/14 11:34, Fam Zheng wrote:
> >> Patch 1 adds a stub for qemu_set_fd_handler which will be referenced in
> >> coming
> >> patches.
> >>
> >> Patch 2 converts qemu-nbd which compares two global numbers i
Paolo Bonzini writes:
> On 14/05/2015 13:47, Michael S. Tsirkin wrote:
>> > I would be OK with a new property too, as we could set it from
>> > libxl or libvirt. Anybody would be happy to pick this one up or should I
>> > do it?
>>
>> Pls go ahead, I can merge it in the pc tree.
>
> Note that bec
On Thu, May 14, 2015 at 01:05:09PM +0200, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
> > Provide a method to change normal, cacheable memory to non-cacheable.
> > KVM will make use of this to keep emulated device memory regions
> > coherent with the gues
On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
> On 05/14/15 15:00, Andrew Jones wrote:
> > On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> >> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> >>> Well, PCI BARs are generally MMIO resources, and hence should not be
>
On Thu, 05/14 12:37, Paolo Bonzini wrote:
> Do other "quick" tests need a QEMU binary?
102
On Thu, 05/14 12:30, Paolo Bonzini wrote:
>
>
> On 12/05/2015 13:48, Fam Zheng wrote:
> > +if (!bdrv_is_allocated_above(source, NULL, sector_num,
> > + nb_sectors, &pnum)) {
> > +op->nb_sectors = pnum;
> > +if (s->source_may_unmap) {
>
> Can yo
On 05/14/15 14:34, Christoffer Dall wrote:
> On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 14/05/2015 14:24, Christoffer Dall wrote:
>>> On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:00, Christoffer Dall wrote:
> So,
On 14/05/2015 15:25, Sander Eikelenboom wrote:
> I tend to kindly disagree if you look at the broader perspective, yes it's
> could
> be a storm in a tea cup, but there seems to be a pattern.
>
> From a "cmdline user" / "platform emulation" point of view i can imagine that
> some sort of
> a
On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote:
>
> Thursday, May 14, 2015, 2:53:17 PM, you wrote:
>
>
>
> > On 14/05/2015 14:45, Markus Armbruster wrote:
> >> Paolo Bonzini writes:
> >>
> >>> On 14/05/2015 14:02, Markus Armbruster wrote:
> It should certainly be of
At 2015/5/14 19:19, Dr. David Alan Gilbert Wrote:
One thing I wanted to check I understand; how much RAM do the active and hidden
disks use; lets say during the 1st checkpoint 10MB of disk is written,
and during hte 2nd checkpoint a different 10MB of the disk is written
(to different location
On 05/14/2015 05:01 AM, Dimitris Aragiorgis wrote:
> Building the QEMU tools fails if we #define DEBUG_BLOCK inside
> block/raw-posix.c. Here instead of adding qemu-log.o in block-obj-y
> so that DEBUG_BLOCK_PRINT can be used, we substitute the latter with
> a simple DPRINTF() (that does not cause
On Thu, 05/14 12:38, Paolo Bonzini wrote:
>
>
> On 14/05/2015 12:29, Wen Congyang wrote:
> >
> > If buf_size % granularity is not 0, mirror_free_init() will
> > do dangerous things.
> >
> > Signed-off-by: Wen Congyang
> > ---
> > block/mirror.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 de
On Thu, May 14, 2015 at 02:02:04PM +0200, Markus Armbruster wrote:
> Correct.
>
> Here's how I think it should be done:
>
> * Create a machine option to control the FDC
>
> This is a machine-specific option. It should only exist for machine
> types that have an optional FDC.
>
> Default
On 05/14/2015 04:35 AM, Paolo Bonzini wrote:
> A bit of Boolean algebra (and common sense) tells us that the
> second "if" here is looking for blocks that are not allocated.
> This is the opposite of the "if" that sets BDRV_BLOCK_ALLOCATED,
> and thus it can use an "else".
>
> Signed-off-by: Paolo
On Thu, 05/14 12:35, Paolo Bonzini wrote:
> A bit of Boolean algebra (and common sense) tells us that the
> second "if" here is looking for blocks that are not allocated.
> This is the opposite of the "if" that sets BDRV_BLOCK_ALLOCATED,
> and thus it can use an "else".
>
> Signed-off-by: Paolo Bo
On 14/05/2015 16:06, Fam Zheng wrote:
> On Thu, 05/14 12:38, Paolo Bonzini wrote:
>>
>>
>> On 14/05/2015 12:29, Wen Congyang wrote:
>>>
>>> If buf_size % granularity is not 0, mirror_free_init() will
>>> do dangerous things.
>>>
>>> Signed-off-by: Wen Congyang
>>> ---
>>> block/mirror.c | 2 +-
On 05/14/15 15:48, Michael S. Tsirkin wrote:
> On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
>> On 05/14/15 15:00, Andrew Jones wrote:
>>> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> Well, PCI BARs are gene
Paolo Bonzini writes:
> On 13/05/2015 18:34, Alexander Yarygin wrote:
>> Ah, right. We need second loop, something like this:
>>
>> @@ -2030,20 +2033,33 @@ void bdrv_drain(BlockDriverState *bs)
>> void bdrv_drain_all(void)
>> {
>> /* Always run first iteration so any pending completion BH
On 14/05/2015 16:29, Alexander Yarygin wrote:
> > Perhaps you can rename bdrv_drain_one to bdrv_flush_io_queue (inlining
> > the existing bdrv_flush_io_queue into it)? That would work very well
> > for me.
>
> Hmm, bdrv_flush_io_queue() is public, but has no users. How about
> different name, ma
On Thu, 14 May 2015, Paolo Bonzini wrote:
> On 14/05/2015 15:25, Sander Eikelenboom wrote:
> > I tend to kindly disagree if you look at the broader perspective, yes it's
> > could
> > be a storm in a tea cup, but there seems to be a pattern.
> >
> > From a "cmdline user" / "platform emulation" p
On Thu, May 14, 2015 at 04:19:23PM +0200, Laszlo Ersek wrote:
> On 05/14/15 15:48, Michael S. Tsirkin wrote:
> > On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
> >> On 05/14/15 15:00, Andrew Jones wrote:
> >>> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> On 1
Do not change default settings for any machines at the moment: this
patch does not introduce any changes in behavior unless the user asks
for no-fdc=on.
Signed-off-by: Stefano Stabellini
---
hw/i386/pc.c | 27 ---
include/hw/i386/pc.h |2 ++
vl.c
On 14/05/2015 16:39, Stefano Stabellini wrote:
> On Thu, 14 May 2015, Paolo Bonzini wrote:
>> On 14/05/2015 15:25, Sander Eikelenboom wrote:
>>> I tend to kindly disagree if you look at the broader perspective, yes it's
>>> could
>>> be a storm in a tea cup, but there seems to be a pattern.
>>>
On 14/05/2015 16:41, Stefano Stabellini wrote:
> Do not change default settings for any machines at the moment: this
> patch does not introduce any changes in behavior unless the user asks
> for no-fdc=on.
Can we avoid the double negative?
Paolo
> Signed-off-by: Stefano Stabellini
> ---
> hw
On Thu, 14 May 2015, Paolo Bonzini wrote:
> On 14/05/2015 16:39, Stefano Stabellini wrote:
> > On Thu, 14 May 2015, Paolo Bonzini wrote:
> >> On 14/05/2015 15:25, Sander Eikelenboom wrote:
> >>> I tend to kindly disagree if you look at the broader perspective, yes
> >>> it's could
> >>> be a stor
1 - 100 of 354 matches
Mail list logo
