> > Obviously, the virtio-balloon mechanism has a bigger performance
> > impact to the guest than the way we are trying to implement.
>
> Yeh, we should separately try and fix that; if it's that slow then people
> will be
> annoyed about it when they're just using it for balloon.
>
> > 3. Virtio
On 03/22/2016 05:40 AM, Alex Williamson wrote:
On Mon, 21 Mar 2016 18:08:44 +0800
Cao jin wrote:
From: Chen Fan
Due to all devices assigned to VM on the same way as host if enable
aer, so we can easily do the hot reset by selecting the function #0
to do the hot reset.
Signed-off-by: Chen F
On 03/22/2016 05:40 AM, Alex Williamson wrote:
On Mon, 21 Mar 2016 18:08:44 +0800
Cao jin wrote:
From: Chen Fan
Due to all devices assigned to VM on the same way as host if enable
aer, so we can easily do the hot reset by selecting the function #0
to do the hot reset.
Signed-off-by: Chen F
This line has been added in commit ef74679a810fe6858f625b9d52b68cc3fc61eb3d with
other initializations. However, scancode set 0 doesn't exist (only 1, 2, 3).
This works well as long as operating system is resetting keyboard, or
overwriting
the current scancode set with the one it wants.
This fixe
global_props is defined in qdev-properties.c. But I can not find where it is
read ans used? Can someone tell me? Thanks!
ch...@foxmail.com
On Wed, Mar 23, 2016 at 02:28:01PM +1100, Alexey Kardashevskiy wrote:
> On 03/23/2016 01:13 PM, David Gibson wrote:
> >On Mon, Mar 21, 2016 at 06:47:06PM +1100, Alexey Kardashevskiy wrote:
> >>This adds support for Dynamic DMA Windows (DDW) option defined by
> >>the SPAPR specification which allows
On Wed, Mar 23, 2016 at 02:06:36PM +1100, Alexey Kardashevskiy wrote:
> On 03/23/2016 01:53 PM, David Gibson wrote:
> >On Wed, Mar 23, 2016 at 01:12:59PM +1100, Alexey Kardashevskiy wrote:
> >>On 03/23/2016 12:08 PM, David Gibson wrote:
> >>>On Tue, Mar 22, 2016 at 04:54:07PM +1100, Alexey Kardashe
I read code in test-qdev-global-props.c. The test function
test_static_globalprop_subprocess is:
static void test_static_globalprop_subprocess(void)
{
MyType *mt;
static GlobalProperty props[] = {
{ TYPE_STATIC_PROPS, "prop1", "200" },
{}
};
qdev_prop_register_glo
> > To make things easier, I wrote this doc about the possible designs and
> > my choices. Comments are welcome!
>
> Thanks for putting this together, and especially for taking the trouble to
> benchmark existing code paths!
>
> I think these numbers do show that there are gains to be had from me
On Wed, Mar 23, 2016 at 3:55 AM, Eric Blake wrote:
> On 03/12/2016 03:23 AM, Pooja Dhannawat wrote:
> > As only DEPTH ==32 case is used, removing other dead code
> > which is based on DEPTH !== 32
> >
> > Signed-off-by: Pooja Dhannawat
> > ---
>
> > +++ b/hw/display/omap_lcdc.c
> > @@ -71,44 +71
On Wed, Mar 23, 2016 at 01:32:29PM +0800, Peter Xu wrote:
> The new command can report which kind of GIC device the host/QEMU
> support. The returned result is in the form of array.
>
> Sample command and output:
>
> {"execute": "query-gic-capability"}
> {"return": [{"emulated": false, "version":
On Tue, Mar 22, 2016 at 02:49:19PM +, Peter Maydell wrote:
> On 18 March 2016 at 03:27, Peter Xu wrote:
> > This patch is to add ARM-specific command "query-gic-capability".
> >
> > The new command can report which kind of GIC device the host/QEMU
> > support. The returned result is in the for
Hello,
I'm the computer science student of Brest State Technical University (Belarus),
and have an idea for Google Summer of Code (I see it as an important feature
and have already started working on it, but mentoring would be a great help).
The proposition is about implementing one more absolu
For emulated GIC capabilities, currently only gicv2 is supported. We
need to add gicv3 in when emulated gicv3 ready. For KVM accelerated ARM
VM, we detect the capability bits by creating a scratch VM.
Signed-off-by: Peter Xu
---
target-arm/monitor.c | 60 +
This patch add "query-gic-capabilities" but does not implemnet it. The
command is ARM-only. The command will return one GICCapabilityResult
object, which contains a array of GICCapability struct that describes
all GIC versions that current QEMU and system support.
Libvirt is possibly the first con
v6 changes:
- patch 1 (squashed into patch 2)
- explain more about the following in commit message: why we need
this command, and what does the entries mean [Markus]
- explain what GIC is [Eric]
- squash this patch into patch 2 [Eric]
- patch 2 (new patch 1)
- fix "does not implement" e
This can be used when probing whether KVM support specific device. Here,
a raw vmfd is used.
Signed-off-by: Peter Xu
---
include/sysemu/kvm.h | 9 +
kvm-all.c| 15 +++
2 files changed, 24 insertions(+)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
ind
Some more lines to make sure we allow NULL for 1st/3rd parameter.
Signed-off-by: Peter Xu
---
target-arm/kvm.c | 10 +-
target-arm/kvm_arm.h | 6 --
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 969ab0b..0a7f9a6 100644
Hi John,
My patch is same as the patch mentioned in the link. I just picked up the
task from BitSizedTask page, as it was not crossed.
I guess the issue is resolved then, what should I do in this case? Also,
please tell me, how do I know which tasks are already taken up?
Regards,
Nutan Shinde.
On Tue, Mar 22, 2016 at 03:20:25PM +0100, Markus Armbruster wrote:
> We discussed the need for a yet another ad hoc query command. Can you
> please summarize the discussion and its conclusion? Explaining *why* a
> feature is needed is always a good idea. Cover letter and commit
> messages are go
On Tue, Mar 22, 2016 at 07:28:13PM +0100, Markus Armbruster wrote:
> Peter Xu writes:
> > diff --git a/scripts/qapi.py b/scripts/qapi.py
> > index 6b2aa6e..716474e 100644
> > --- a/scripts/qapi.py
> > +++ b/scripts/qapi.py
> > @@ -46,6 +46,7 @@ returns_whitelist = [
># Whitelist of commands al
On Tue, Mar 22, 2016 at 12:42:42PM -0600, Eric Blake wrote:
> On 03/17/2016 09:27 PM, Peter Xu wrote:
> > This patch adds the command "query-gic-capabilities" but not implemnet
>
> s/not implemnet/does not implement/
Yep, again. Thanks.
>
> > it. The command is ARM-only. Return of the command i
On 03/02/2016 05:13 PM, Markus Armbruster wrote:
This got lost over the Christmas break, sorry.
Cc'ing Marcel for additional PCI expertise.
Cao jin writes:
msi_init() is a supporting function in PCI device initialization,
in order to convert .init() to .realize(), it should be modified firs
On 03/22/2016 07:17 PM, Michael S. Tsirkin wrote:
On Thu, Mar 17, 2016 at 04:32:46PM +0800, Xiao Guangrong wrote:
This patchset is against commit d4207b223eef3 (fw-cfg: support writeable
blobs) on pci branch of Michael's git tree and can be found at:
https://github.com/xiaogr/qemu.git n
On 03/17/2016 06:58 PM, Stefan Hajnoczi wrote:
On Thu, Mar 17, 2016 at 04:32:58PM +0800, Xiao Guangrong wrote:
-/* No function except function 0 is supported yet. */
-nvdimm_dsm_no_payload(1 /* Not Supported */, dsm_mem_addr);
+if (!nvdimm) {
+return nvdimm_dsm_no_payload(1
On Wed, Mar 16, 2016 at 10:11:54AM +0530, Bharata B Rao wrote:
> On Wed, Mar 16, 2016 at 12:36:05PM +1100, David Gibson wrote:
> > On Tue, Mar 15, 2016 at 10:08:56AM +0530, Bharata B Rao wrote:
> > > Add support to hot remove pc-dimm memory devices.
> > >
> > > Signed-off-by: Bharata B Rao
> >
>
On 03/17/2016 06:35 PM, Stefan Hajnoczi wrote:
On Thu, Mar 17, 2016 at 04:32:56PM +0800, Xiao Guangrong wrote:
+static void
+nvdimm_dsm_function0(uint32_t supported_func, hwaddr dsm_mem_addr)
+{
+NvdimmDsmFunc0Out func0 = {
+.len = cpu_to_le32(sizeof(func0)),
+.supported_fu
On 03/17/2016 06:28 PM, Stefan Hajnoczi wrote:
On Thu, Mar 17, 2016 at 04:32:50PM +0800, Xiao Guangrong wrote:
+static void nvdimm_init(Object *obj)
+{
+object_property_add_bool(obj, "reserve-label", nvdimm_get_reserve_label,
+ nvdimm_set_reserve_label, NULL);
Add more useful error information to failure paths in vpc_open
Signed-off-by: Jeff Cody
---
block/vpc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/block/vpc.c b/block/vpc.c
index 67ab376..5dd9950 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -237,6 +237,7 @@ static int vpc_open
Signed-off-by: Jeff Cody
---
block/vpc.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index 5dd9950..0b48cf4 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -36,7 +36,7 @@
#define HEA
The old VHD_MAX_SECTORS value is incorrect, and is a throwback
to the CHS calculations. The VHD specification allows images up to 2040
GiB, which (using 512 byte sectors) corresponds to a maximum number of
sectors of 0xff00, rather than the old value of 0xfe0001ff.
Update VHD_MAX_SECTORS to r
XenConverter VHD images are another VHD image where current_size is
different from the CHS values in the the format header. Use
current_size as the default, by looking at the creator_app signature
field.
Signed-off-by: Jeff Cody
---
block/vpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --gi
The check on the max_table_size field not being larger than required is
valid, and in accordance with the VHD spec. However, there have been
VHD images encountered in the wild that have an out-of-spec max table
size that is technically too large.
There is no issue in allowing this larger table si
From: Stefan Hajnoczi
The vpc driver has two methods of determining virtual disk size. The
correct one to use depends on the software that generated the image
file. Add the XenServer creator_app signature so that image size is
correctly detected for those images.
Reported-by: Grant Wu
Reporte
Commit 'b8f45cdf7827e39f9a1e6cc446f5972cc6144237' switched VPC
over to using blk_pwrite() instead of bdrv_pwrite_sync(). The
return value of bdrv_pwrite_sync() was always 0 for success, and
create_dynamic_disk() in one instance checked for a non-zero return
value to indicate error. However, blk_p
Fixes for a regression in vpc_create(), as well as a few issues with VHD format
compatibility.
Jeff Cody (6):
block/vpc: fix VPC 'qemu-img create' regression
block/vpc: use current_size field for XenConverter VHD images
block/vpc: Use the correct max sector count for VHD images
block/vpc:
On 03/23/2016 01:13 PM, David Gibson wrote:
On Mon, Mar 21, 2016 at 06:47:06PM +1100, Alexey Kardashevskiy wrote:
This adds support for Dynamic DMA Windows (DDW) option defined by
the SPAPR specification which allows to have additional DMA window(s)
This implements DDW for emulated and VFIO dev
On Tue, Mar 22, 2016 at 12:32:28PM -0600, Eric Blake wrote:
> On 03/17/2016 09:27 PM, Peter Xu wrote:
> > +##
> > +# @GICCapability:
> > +#
> > +# This struct describes capability for a specific GIC version. These
>
> Might be nice to spell out what the acronym GIC means, but that's cosmetic.
Ah!
On 03/23/2016 01:53 PM, David Gibson wrote:
On Wed, Mar 23, 2016 at 01:12:59PM +1100, Alexey Kardashevskiy wrote:
On 03/23/2016 12:08 PM, David Gibson wrote:
On Tue, Mar 22, 2016 at 04:54:07PM +1100, Alexey Kardashevskiy wrote:
On 03/22/2016 04:14 PM, David Gibson wrote:
On Mon, Mar 21, 2016
On Tue, Mar 22, 2016 at 07:41:17PM +0100, Markus Armbruster wrote:
> Markus Armbruster writes:
> >> +##
> >> +# @GICCapability:
> >> +#
> >> +# This struct describes capability for a specific GIC version. These
> >> +# bits are not only decided by QEMU/KVM software version, but also
> >> +# decide
On Wed, Mar 23, 2016 at 01:12:59PM +1100, Alexey Kardashevskiy wrote:
> On 03/23/2016 12:08 PM, David Gibson wrote:
> >On Tue, Mar 22, 2016 at 04:54:07PM +1100, Alexey Kardashevskiy wrote:
> >>On 03/22/2016 04:14 PM, David Gibson wrote:
> >>>On Mon, Mar 21, 2016 at 06:47:05PM +1100, Alexey Kardashe
Sorry for the delay and i just come back from my vacation.
On 03/23/2016 04:30 AM, Stefan Hajnoczi wrote:
On Tue, Mar 22, 2016 at 08:37:40AM -0700, Dan Williams wrote:
On Thu, Mar 17, 2016 at 3:04 AM, Stefan Hajnoczi wrote:
On Thu, Mar 17, 2016 at 04:32:46PM +0800, Xiao Guangrong wrote:
Thi
On Tue, Mar 22, 2016 at 03:07:00PM -0400, Bandan Das wrote:
> Thank you Peter, I wasn't aware. But unfortunately, I don't think he's doing
> the right
> thing either when handing @end ? Oh well, it's a RFC :)
Possibly. Just to make sure you know about the whole thing (rather
than only the @end f
On Mon, Mar 21, 2016 at 06:47:06PM +1100, Alexey Kardashevskiy wrote:
> This adds support for Dynamic DMA Windows (DDW) option defined by
> the SPAPR specification which allows to have additional DMA window(s)
>
> This implements DDW for emulated and VFIO devices.
> This reserves RTAS token number
On Tue, Mar 22, 2016 at 12:53:15PM +, Alex Bennée wrote:
> The move from Travis VMs to Containers came with a upgrade from 1.5
> cores to 2. The received wisdom is -j N+1 means a core can be doing work
> while other threads wait for IO to complete. This is hard to test on the
> Travis infrastru
On 03/23/2016 12:08 PM, David Gibson wrote:
On Tue, Mar 22, 2016 at 04:54:07PM +1100, Alexey Kardashevskiy wrote:
On 03/22/2016 04:14 PM, David Gibson wrote:
On Mon, Mar 21, 2016 at 06:47:05PM +1100, Alexey Kardashevskiy wrote:
New VFIO_SPAPR_TCE_v2_IOMMU type supports dynamic DMA window manag
Hi, Liang
This is a very clear documentation of your work, I appreciated it a lot. Below
are some of my personal opinion and question.
On Tue, Mar 22, 2016 at 03:43:49PM +0800, Liang Li wrote:
>I have sent the RFC version patch set for live migration optimization
>by skipping processing the free
On Tue, Mar 22, 2016 at 04:54:07PM +1100, Alexey Kardashevskiy wrote:
> On 03/22/2016 04:14 PM, David Gibson wrote:
> >On Mon, Mar 21, 2016 at 06:47:05PM +1100, Alexey Kardashevskiy wrote:
> >>New VFIO_SPAPR_TCE_v2_IOMMU type supports dynamic DMA window management.
> >>This adds ability to VFIO com
On Tue, Mar 22, 2016 at 09:47:10AM -0600, Alex Williamson wrote:
> On Tue, 22 Mar 2016 14:05:15 +1100
> David Gibson wrote:
>
> > On Mon, Mar 21, 2016 at 06:47:00PM +1100, Alexey Kardashevskiy wrote:
> > > At the moment IOMMU MR only translate to the system memory.
> > > However if some new code
On Tue, Mar 22, 2016 at 03:23:13PM +0100, Cédric Le Goater wrote:
> commit fce55481360d "ppc: A couple more dummy POWER8 Book4 regs"
> squashed in to rapidly a set of POWER8 Book4 regs in the wrong
> routine. This patch introduces the missing gen_spr_power8_book4()
> routine to fix their location.
On Tue, Mar 22, 2016 at 12:53:13PM +, Alex Bennée wrote:
> Remove the concept of TARGETS and build the complete target list for
> each config combination. Now the matrix is just based on CONFIG stanzas
> and we use the additional stuff for:
>
> - things that only work on one compiler (sparse
On 03/23/2016 02:47 AM, Alex Williamson wrote:
On Tue, 22 Mar 2016 14:05:15 +1100
David Gibson wrote:
On Mon, Mar 21, 2016 at 06:47:00PM +1100, Alexey Kardashevskiy wrote:
At the moment IOMMU MR only translate to the system memory.
However if some new code changes this, we will need clear ind
On 03/22/2016 03:41 AM, Isaac Lozano wrote:
> qemu_hexdump() in util/hexdump.c has been changed to give also include a
> ascii dump of the buffer. Also, calls to hex_dump() in net/net.c have
> been replaced with calls to qemu_hexdump(). This takes care of two misc
> BiteSized Tasks.
>
> Signed-o
Hello Peter,
Peter Maydell, on Fri 19 Feb 2016 12:09:17 +, wrote:
> diff --git a/slirp/mbuf.h b/slirp/mbuf.h
> index 38fedf4..ef5a4f7 100644
> --- a/slirp/mbuf.h
> +++ b/slirp/mbuf.h
> @@ -81,11 +81,9 @@ struct mbuf {
> Slirp *slirp;
> boolresolution_requested;
> ui
On Tue, Mar 22, 2016 at 06:19:40PM +1100, Alexey Kardashevskiy wrote:
> On 03/22/2016 03:59 PM, David Gibson wrote:
> >On Tue, Mar 22, 2016 at 03:28:52PM +1100, Alexey Kardashevskiy wrote:
> >>On 03/22/2016 02:26 PM, David Gibson wrote:
> >>>On Tue, Mar 22, 2016 at 02:12:30PM +1100, Alexey Kardashe
On Tue, Mar 22, 2016 at 08:05:08AM +0100, Cédric Le Goater wrote:
> On 03/22/2016 12:15 AM, David Gibson wrote:
> > On Mon, Mar 21, 2016 at 01:52:34PM +0100, Cédric Le Goater wrote:
> >> From: Benjamin Herrenschmidt
> >>
> >> And move the code adjusting the MSR mask and calling kvmppc_set_papr()
>
On Tue, Mar 22, 2016 at 05:24:33PM +1100, Alexey Kardashevskiy wrote:
> On 03/22/2016 03:45 PM, David Gibson wrote:
> >On Mon, Mar 21, 2016 at 06:47:04PM +1100, Alexey Kardashevskiy wrote:
> >>The sPAPR TCE tables manage 2 copies when VFIO is using an IOMMU -
> >>a guest view of the table and a har
Quoting Peter Lieven (2016-03-22 05:00:28)
> Am 21.03.2016 um 18:27 schrieb Michael Roth:
> > Hi everyone,
> >
> > The following new patches are queued for QEMU stable v2.5.1:
> >
> >https://github.com/mdroth/qemu/commits/stable-2.5-staging
> >
> > The release is planned for 2016-03-29:
> >
> >
Quoting Greg Kurz (2016-03-22 02:49:35)
> On Mon, 21 Mar 2016 12:28:26 -0500
> Michael Roth wrote:
>
> > From: Greg Kurz
> >
> > Since QEMU 2.4, we have a configuration section in the migration stream.
> > This must be skipped for older machines, like it is already done for x86.
> >
> > This p
Quoting Cole Robinson (2016-03-21 14:32:14)
> On 03/21/2016 01:27 PM, Michael Roth wrote:
> > Hi everyone,
> >
> > The following new patches are queued for QEMU stable v2.5.1:
> >
> > https://github.com/mdroth/qemu/commits/stable-2.5-staging
> >
> > The release is planned for 2016-03-29:
> >
On 03/12/2016 03:23 AM, Pooja Dhannawat wrote:
> As only DEPTH ==32 case is used, removing other dead code
> which is based on DEPTH !== 32
>
> Signed-off-by: Pooja Dhannawat
> ---
> +++ b/hw/display/omap_lcdc.c
> @@ -71,44 +71,23 @@ static void omap_lcd_interrupts(struct omap_lcd_panel_s
> *s)
On 21/03/2016 18:19, Markus Armbruster wrote:
> I think only if some our users actually expect the alternate wart can we
> seriosuly consider switching, because then we have to choose between two
> breakages anyway:
>
> * We can stick to the current wart, and leave these users broken.
>
> * We
On 21/03/2016 18:39, Kevin Wolf wrote:
> > When I wrote my review, I forgot that I expect x-blockdev-del to accept
> > only backends created with blockdev-add. With that, my question is
> > indeed moot.
> >
> > However, I've now tested my expectation, and it turned out to be wrong.
> > I'm incl
On 03/22/2016 12:34 AM, Nutan Shinde wrote:
> Signed-off-by: Nutan Shinde
> ---
> hw/display/blizzard.c | 8
> hw/display/blizzard_template.h | 26 +-
> hw/display/omap_lcd_template.h | 8 +---
> hw/display/omap_lcdc.c | 6 --
> hw/disp
On 22/03/2016 11:25, Markus Armbruster wrote:
> Regardless of how and when we create BlockBackend, we'll want to keep
> the clean separation between frontend and backend internally and at the
> user interface.
This means that the BlockBackend should not own the DriveInfo. The
backend and fronte
On 03/22/2016 02:34 AM, Nutan Shinde wrote:
> Signed-off-by: Nutan Shinde
> ---
> hw/display/blizzard.c | 8
> hw/display/blizzard_template.h | 26 +-
> hw/display/omap_lcd_template.h | 8 +---
> hw/display/omap_lcdc.c | 6 --
> hw/di
The following changes since commit 4829e0378dfb91d55af9dfd741bd09e8f2c4f91a:
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2016-03-18' into
staging (2016-03-18 17:18:41 +)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
for you
On 03/22/2016 09:33 AM, Kevin Wolf wrote:
> Some features, like I/O throttling, are implemented outside
> block-backend.c, but still want to keep BlockBackends in a list. In
> order to avoid exposing the whole struct layout in the public header
> file, this patch introduces an embedded public struc
On 03/15/2016 04:04 PM, Vladimir Sementsov-Ogievskiy wrote:
> Add functions for load/store HBitmap to BDS, using clusters table:
> Last level of the bitmap is splitted into chunks of 'cluster_size'
> size. Each cell of the table contains offset in bds, to load/store
> corresponding chunk.
>
> Al
On 03/22/2016 09:33 AM, Kevin Wolf wrote:
> It was already true in principle that a throttled BDS always has a BB
> attached, except that the order of operations while attaching or
> detaching a BDS to/from a BB wasn't careful enough.
>
> This commit breaks graph manipulations while I/O throttling
Hello,
Markus Armbruster, on Mon 21 Mar 2016 08:33:52 +0100, wrote:
> > -# @net: #optional IP address and optional netmask
> > +# @net: #optional IP address and optional netmask. Set to 0.0.0.0 to
> > disable IPv4 completely
>
> Long line.
>
> Syntax? Default value?
Something like this?
# @n
On 03/21/2016 05:09 PM, Peter Maydell wrote:
> On 21 March 2016 at 18:00, John Snow wrote:
>> Looks like one of your libraries is outdated, for me
>> 'IBV_LINK_LAYER_INFINIBAND' is defined in
>> /usr/include/infiniband/verbs.h; provided by
>> libibverbs-devel-1.1.8-3.fc22.x86_64.
>>
>> Maybe you
On 03/22/2016 09:33 AM, Kevin Wolf wrote:
> We had to disable I/O throttling with synchronous requests because we
> didn't use to run timers in nested event loops when the code was
> introduced. This isn't true any more, and throttling works just fine
> even when using the synchronous API.
>
> The
On 03/10/2016 11:59 AM, Daniel P. Berrange wrote:
> The VNC server has historically had support for ACLs to check
> both the SASL username and the TLS x509 distinguished name.
> The VNC server was responsible for creating the initial ACL,
> and the client app was then responsible for populating it
On 22/03/2016 20:36, Kevin Wolf wrote:
> This is the final patch series that is required before we can start allowing
> setups with more than one BlockBackend per BlockDriverState.
>
> My current plan is to put the patches up to (and including) this series into
> 2.6 so that we have a relatively
On 22/03/2016 16:33, Kevin Wolf wrote:
> This is another feature that was "logically" part of the BlockBackend, but
> implemented as a BlockDriverState feature. It was always kept on top using
> swap_feature_fields().
>
> This series moves it to be actually implemented in the BlockBackend, removin
On 22/03/2016 21:27, Peter Maydell wrote:
>
> PPC64 Linux:
>
> /home/pm215/qemu/hw/intc/openpic_kvm.c: In function 'kvm_openpic_realize':
> /home/pm215/qemu/hw/intc/openpic_kvm.c:207:9: error: implicit
> declaration of function 'error_setg'
> [-Werror=implicit-function-declaration]
> e
On 03/10/2016 11:59 AM, Daniel P. Berrange wrote:
> Currently any client which can complete the TLS handshake
> is able to use a chardev server. The server admin can turn
> on the 'verify-peer' option for the x509 creds to require
> the client to provide a x509 certificate. This means the
> client
Alex Williamson writes:
...
>>
>> And it does. If we fix this assert, then vfio_dma_map() attempts mapping
>> this direct mapped address range starting from 0 and prints a
>> warning message; happens for the whole range and goes on for ever.
>> The overflow check seemed to me like something we s
On Tue, Mar 22, 2016 at 08:37:40AM -0700, Dan Williams wrote:
> On Thu, Mar 17, 2016 at 3:04 AM, Stefan Hajnoczi wrote:
> > On Thu, Mar 17, 2016 at 04:32:46PM +0800, Xiao Guangrong wrote:
> >> This patchset is against commit d4207b223eef3 (fw-cfg: support writeable
> >> blobs) on pci branch of Mic
On 22 March 2016 at 14:16, Paolo Bonzini wrote:
> The following changes since commit 4829e0378dfb91d55af9dfd741bd09e8f2c4f91a:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2016-03-18'
> into staging (2016-03-18 17:18:41 +)
>
> are available in the git repository at:
>
>
On 22 March 2016 at 19:23, Lluís Vilanova wrote:
> Peter Maydell writes:
>> Well, that's why I'm not certain about it. I would prefer us to
>> not trace the accesses rather than put a trace in a wrong
>> position.
>
> Theoretically, that's what DEBUG_REMAP is for. A temporary host buffer is
> allo
ble in the git repository at:
>
> https://github.com/bkoppelmann/qemu-tricore-upstream.git
> tags/pull-tricore-20160322
>
> for you to fetch changes up to d66718ccf37b71eff686c3d6116223889736188f:
>
> target-tricore: Add ftoi and itof instructions (2016-03-21 18:04:16 +01
Since virtio-blk implements request merging itself these days, the only
remaining users are test cases for the function. That doesn't make the
function exactly useful any more.
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 14 ---
block/io.c | 194 --
This patch removes the remaining users of bs->blk, which will allow us
to have multiple BBs on top of a single BDS. All checks that are
currently in place to prevent the user from creating such setups.
Future patches can allow them and e.g. enable users to mirror to a block
device that already has
query-named-block-nodes should not return information that is related
to the attached BlockBackend rather than the node itself, so throttling
information needs to be removed from it.
Signed-off-by: Kevin Wolf
---
block/qapi.c | 6 +++---
tests/qemu-iotests/096 | 3 ++-
2 files changed,
The block jobs currently modify the target BB's error handling options
and require that the source BB's iostatus is enabled in order to
implement the per-job error options. It's obvious that this is something
between ugly, adventurous and plain wrong, so we should ideally fix this
instead of thinki
bdrv_move_feature_fields() and swap_feature_fields() are empty now, they
can be removed.
Signed-off-by: Kevin Wolf
---
block.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/block.c b/block.c
index 66f918e..3770fb0 100644
--- a/block.c
+++ b/block.c
@@ -,1
We just want to know whether a BDS has at least one BB attached in order
to avoid enumerating it twice. This doesn't depend on the exact BB that
is attached and is still a valid question when more than one BB can be
attached, so just answer it by checking the parents list.
Signed-off-by: Kevin Wol
We need to introduce a separate BdrvNextIterator struct that can keep
more state than just the current BDS in order to avoid using the bs->blk
pointer.
Signed-off-by: Kevin Wolf
---
block.c| 34 +---
block/block-backend.c | 44
We want to get rid of BlockDriverState.blk in order to allow multiple
BlockBackends per BDS. Converting the device callbacks in block.c (which
assume a single BlockBackend) to per-child callbacks gets us rid of the
first few instances.
Signed-off-by: Kevin Wolf
---
block.c | 38
In order to get rid of bs->blk for bdrv_get_device_name() and
bdrv_get_device_or_node_name(), ask all parents for their name and
simply pick the first one.
Signed-off-by: Kevin Wolf
---
block.c | 22 --
block/block-backend.c | 6 ++
include/block/bl
This is the final patch series that is required before we can start allowing
setups with more than one BlockBackend per BlockDriverState.
My current plan is to put the patches up to (and including) this series into
2.6 so that we have a relatively consistent block layer state in the release
that i
On Tue, 22 Mar 2016 15:07:00 -0400
Bandan Das wrote:
> Peter Xu writes:
>
> > On Mon, Mar 21, 2016 at 06:00:50PM -0400, Bandan Das wrote:
> >>
> >> vfio_listener_region_add for a iommu mr results in
> >> an overflow assert since emulated iommu memory region is initialized
> >> with UINT64_MA
On Tue, 22 Mar 2016 14:55:14 -0400
Bandan Das wrote:
> Alex Williamson writes:
> ...
> >> >>mr->size = int128_make64(size);
> >> >>if (size == UINT64_MAX) {
> >> >> mr->size = int128_2_64();
> >> >>}
> >> >> So, end - 1 is still valid for end = UINT64_MAX, no ?
> >> >
> >>
Eric Blake writes:
> On 03/17/2016 09:27 PM, Peter Xu wrote:
>> This patch adds the command "query-gic-capabilities" but not implemnet
>
> s/not implemnet/does not implement/
>
>> it. The command is ARM-only. Return of the command is a list of
>> GICCapability struct that describes all GIC versio
Peter Maydell writes:
> On 22 March 2016 at 14:02, Lluís Vilanova wrote:
>> Stefan Hajnoczi writes:
>>
>>> On Wed, Mar 16, 2016 at 03:10:01PM +, Peter Maydell wrote:
The first two patches which add TCG guest data access tracing look
OK to me, but I'm much less sure about the last t
Peter Xu writes:
> On Mon, Mar 21, 2016 at 06:00:50PM -0400, Bandan Das wrote:
>>
>> vfio_listener_region_add for a iommu mr results in
>> an overflow assert since emulated iommu memory region is initialized
>> with UINT64_MAX. Add a check just like memory_region_size()
>> does.
>
> Hi, Bandan,
* Liang Li (liang.z...@intel.com) wrote:
> I have sent the RFC version patch set for live migration optimization
> by skipping processing the free pages in the ram bulk stage and
> received a lot of comments. The related threads can be found at:
Thanks!
> Obviously, the virtio-balloon mechanism
Alex Williamson writes:
...
>> >>mr->size = int128_make64(size);
>> >>if (size == UINT64_MAX) {
>> >> mr->size = int128_2_64();
>> >>}
>> >> So, end - 1 is still valid for end = UINT64_MAX, no ?
>> >
>> > int128_2_64() is not equal to UINT64_MAX, so assigning UIN64_MAX to
>> >
1 - 100 of 300 matches
Mail list logo
