2015-12-04 21:18 GMT+08:00 Eric Blake :
> On 12/04/2015 02:19 AM, Miao Yan wrote:
>> Vmxnet3 uses the following debug macro style:
>>
>
> When sending a patch series, it's best to include a 0/2 cover letter
> (some of the maintainer tooling works better if it can reply to the
> cover letter).
>
> A
On 12/05/2015 12:38 AM, Vladimir Sementsov-Ogievskiy wrote:
On 16.11.2015 13:50, Xiao Guangrong wrote:
NVDIMM (A Non-Volatile Dual In-line Memory Module) is going to be supported
on Intel's platform.
Hi.
One question: do this mean, that your qemu emulated nvidimm - pmem solution
will work
On 01.12.2015 [14:41:25 +1100], David Gibson wrote:
> On Thu, Nov 12, 2015 at 08:46:27AM -0800, Nishanth Aravamudan wrote:
> > On 12.11.2015 [15:47:15 +1100], David Gibson wrote:
> > > On Wed, Nov 11, 2015 at 02:10:48PM -0800, Nishanth Aravamudan wrote:
> > > > On 11.11.2015 [12:41:26 +1100], David
On 04.12.2015 22:34, Max Reitz wrote:
> On 03.12.2015 11:01, Bo Tu wrote:
>> From: Bo Tu
>>
>> v4:
>> 1. Remove 051.s390.out, and rollback the changes in Makefile to generate
>> 051.s390-ccw-virtio.out
>> 2. Use 051.out as the common output for any non-pc platform
>> 3. Set device_id to "drive0",
On 01.12.2015 17:01, Kevin Wolf wrote:
> Am 10.11.2015 um 04:27 hat Max Reitz geschrieben:
>> Move bdrv_drain_all(), bdrv_commit_all(), bdrv_flush_all() and
>> bdrv_invalidate_cache_all() to BB.
>>
>> The only operation left is bdrv_close_all(), which cannot be moved to
>> the BB because it should
Hi Max:
在 2015/12/5 5:21, Max Reitz 写道:
On 03.12.2015 11:01, Bo Tu wrote:
From: Bo Tu
The tests for ide device should only be tested for the pc
platform.
Set device_id to "drive0", and replace every "-drive file..."
by "-drive file=...,if=none,id=$device_id", then x86 and s390x
can get the co
On 04.12.2015 14:35, Kevin Wolf wrote:
> This adds the cache mode options to the QDict, so that they can be
> specified for child nodes (e.g. backing.cache.direct=off).
>
> The cache modes are not removed from the flags at this point; instead,
> options and flags are kept in sync. If the user spec
On 04.12.2015 14:35, Kevin Wolf wrote:
> Creating an empty drive while specifying 'format' doesn't make sense.
> The specified format driver would simply be ignored.
>
> Make a set 'format' option an indication that a non-empty drive should
> be created. This makes 'format' consistent with 'driver
On 04.12.2015 14:35, Kevin Wolf wrote:
> Some drivers have nested options (e.g. blkdebug rule arrays), which
> don't belong to a child node and shouldn't be removed. Don't remove all
> options with "." in their name, but check for the complete prefixes of
> actually existing child nodes.
>
> Signe
On 03.12.2015 11:01, Bo Tu wrote:
> From: Bo Tu
>
> v4:
> 1. Remove 051.s390.out, and rollback the changes in Makefile to generate
> 051.s390-ccw-virtio.out
> 2. Use 051.out as the common output for any non-pc platform
> 3. Set device_id to "drive0", and replace every "-drive file..."
> by "-dri
On 03.12.2015 11:01, Bo Tu wrote:
> From: Bo Tu
>
> The tests for ide device should only be tested for the pc
> platform.
> Set device_id to "drive0", and replace every "-drive file..."
> by "-drive file=...,if=none,id=$device_id", then x86 and s390x
> can get the common output in the test of "S
On 11/25/2015 05:23 PM, Eric Blake wrote:
> Cache the visitor in a local variable instead of repeatedly
> calling the accessor. Pass NULL for the visit_start_struct()
> object (which matches the fact that we were already passing 0
> for the size argument, because we aren't using the visit to
> all
CMD23 is optional for SD but required for MMC, and Tianocore EDK2
(UEFI) uses it at boot.
Signed-off-by: Andrew Baumann
---
For EDK2 to boot all we actually need to do is return success and
ignore the command, but it seemed much safer to implement the full
semantics.
hw/sd/sd.c | 48 +++
The SD spec for ACMD41 says that a zero argument is an "inquiry"
ACMD41, which does not start initialisation and is used only for
retrieving the OCR. However, Tianocore EDK2 (UEFI) has a bug [1]: it
first sends an inquiry (zero) ACMD41. If that first request returns an
OCR value with the power up b
This series contains two fixes to the SD card emulation that are
needed to unblock Tianocore EDK2 UEFI builds (including the bootloader
for Windows on Raspberry Pi 2) from booting.
(I'm guessing at the CC list here, since this code appears to be
unmaintained. Apologies if I guessed wrong!)
Cheers
Thanks Jason,
On Fri, 4 Dec 2015 16:49:52 +0800 Jason Wang wrote:
> > @@ -2257,6 +2262,10 @@ static void vmxnet3_pci_realize(PCIDevice *pci_dev,
> > Error **errp)
> >
> > vmxnet3_net_init(s);
> >
> > +if (pci_is_express(pci_dev) && pci_bus_is_express(pci_dev->bus)) {
>
> Looks like
"Li, Liang Z" wrote:
>> > There are some flaws in qemu_put_compression_data, this patch tries to
>> > fix it. Now it can be used by other code.
>> >
>> > Signed-off-by: Liang Li
>> > ---
>> > migration/qemu-file.c | 10 +-
>> > 1 file changed, 9 insertions(+), 1 deletion(-)
>> >
>> > dif
Thanks Jason,
On Fri, 4 Dec 2015 16:49:23 +0800 Jason Wang wrote:
> > @@ -18,6 +18,10 @@
> > .driver = "virtio-pci",\
> > .property = "migrate-extra",\
> > .value= "off",\
> > +},{\
> > +.driver = "vmxnet3",\
> > +.pro
On Fri, Dec 04, 2015 at 10:50:21AM -0800, Peter Crosthwaite wrote:
> > FWIW, I don't think the SD card will be qdevified because it doesn't
> > need a bus. It's similar indeed to SerialState, which was supposed to
> > be the poster child of QOM embedding and never got QOMified.
>
> SD is a bus in
This series fixes two niggles in the lan9118 emulation. Together,
these are enough for it to work with a simple driver for the SMSC 9221
(which is very similar).
Cheers,
Andrew
Andrew Baumann (2):
lan9118: fix emulation of MAC address loaded bit in E2P_CMD register
lan9118: log and ignore acc
With this change, access to invalid/unimplemented device registers are
logged as a "guest error" rather than aborting qemu with
hw_error. This enables drivers for similar devices (e.g. SMSC 9221),
by simply ignoring the unimplemented writes. It's also closer to what
real hardware does.
Signed-off-
There appears to have been a longstanding typo in the implementation
of the "MAC address loaded" bit in the E2P_CMD (EEPROM command)
register. The code was using 0x10, but the controller spec says it
should be bit 8 (0x100).
Signed-off-by: Andrew Baumann
---
This may have slipped through, because
On Fri, Dec 4, 2015 at 8:42 AM, Paolo Bonzini wrote:
>
>
> On 04/12/2015 12:00, Peter Maydell wrote:
>> On 4 December 2015 at 07:30, Markus Armbruster wrote:
>>> Peter Maydell writes:
>>>
On 7 September 2015 at 17:57, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On 7
On Fri, Dec 04, 2015 at 12:55:07PM +, Peter Maydell wrote:
> On 4 December 2015 at 12:50, Markus Armbruster wrote:
> > To finally answer your question: the proper owner of the property
> > connecting the backend is the frontend half of the split device. So, if
> > we have separate device mode
> >> we are now comparing enum with enum which are the same type.
> >> With the change you are proposing we will compare enum
> >> with u32 which are different.
> > This is only an issue in C++.
> >
> >> Original suggestion from Andrey was safe in this respect.
> > Sure, but it makes code less cle
On 12/04/2015 08:38 PM, Paolo Bonzini wrote:
On 04/12/2015 17:55, Denis V. Lunev wrote:
On 12/04/2015 05:41 PM, Paolo Bonzini wrote:
On 04/12/2015 15:33, Denis V. Lunev wrote:
On 12/02/2015 03:22 PM, Paolo Bonzini wrote:
On 30/11/2015 17:22, Andrey Smetanin wrote:
enum hv_message_type insid
From: Markus Armbruster
We have several function parameters declared as void (*fn). This is
just a stupid way to write void *, and the only purpose writing it
like that could serve is obscuring the sin of bypassing the type
system without need.
The original sin is commit 49ee359: its qtest_add_
From: Cao jin
It doesn't have "GSList *interfaces" anymore, drop the paragraph.
Signed-off-by: Cao jin
Signed-off-by: Andreas Färber
---
include/qom/object.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/qom/object.h b/include/qom/object.h
index f172fea..4509166 100644
--- a/i
Hello Peter,
This is my QOM (devices) patch queue for 2.5. Please pull.
v2 squashes a fix by Markus.
Regards,
Andreas
Cc: Peter Maydell
Cc: Markus Armbruster
Cc: Marc-André Lureau
The following changes since commit 4c65fed8bdf96780735dbdb92a8bd0d6b6526cc3:
ui: vnc: avoid floating point e
From: Marc-André Lureau
Before this patch ASAN reported:
SUMMARY: AddressSanitizer: 677165875 byte(s) leaked in 1272437 allocation(s)
After this patch:
SUMMARY: AddressSanitizer: 465 byte(s) leaked in 32 allocation(s)
Signed-off-by: Marc-André Lureau
Message-Id: <1448551895-871-1-git-send-emai
Commit e253c28 ("tests: Fix how qom-test is run") introduced
$(qtest-generic-y) and used it for check-qtest-% target, but did not
update check-report-qtest-%. This causes check-report-qtest-aarch64.xml
target to fail with a gtester usage error for lack of test arguments.
Fix this by adding $(qtest
On 12/04/2015 02:47 AM, Cao jin wrote:
> Hi,
> As you know, there are many PCI devices still using .init() as its
> initialization function, I am planning to do the "convert to realize()"
> work, and PCI bridge devices are chosen first.
> The supporting functions should be modifie
Hello Michael,
On Fri, Dec 04, 2015 at 04:50:03PM +0100, Michael Kerrisk (man-pages) wrote:
> Hi Andrea,
>
> On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote:
> > On 05/14/2015 07:30 PM, Andrea Arcangeli wrote:
> >> Add documentation.
> >
> > Hi Andrea,
> >
> > I do not recall... Did y
On 04/12/2015 17:55, Denis V. Lunev wrote:
> On 12/04/2015 05:41 PM, Paolo Bonzini wrote:
>>
>> On 04/12/2015 15:33, Denis V. Lunev wrote:
>>> On 12/02/2015 03:22 PM, Paolo Bonzini wrote:
On 30/11/2015 17:22, Andrey Smetanin wrote:
> enum hv_message_type inside struct hv_message, hv_post
Our use of glib is now pervasive across QEMU. Move the include of glib-compat.h
from qemu-common.h to osdep.h so that it is more widely accessible and doesn't
get forgotten by accident. (Failure to include it will result in build failure
on old versions of glib which is likely to be unnoticed by mo
On 12/04/2015 08:32 AM, Lan, Tianyu wrote:
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's impossible to change
Windows kernel.
That is a poor argu
On 12/04/2015 05:41 PM, Paolo Bonzini wrote:
On 04/12/2015 15:33, Denis V. Lunev wrote:
On 12/02/2015 03:22 PM, Paolo Bonzini wrote:
On 30/11/2015 17:22, Andrey Smetanin wrote:
enum hv_message_type inside struct hv_message, hv_post_message
is not size portable. Replace enum by u32.
It's only
On 4 December 2015 at 16:39, Paolo Bonzini wrote:
>
>> I don't think we've ever said "we should transition away from HWADDR_*",
>> but whether we should is an interesting question, which is why I asked.
>> Does retaining the format macros to go with the typedef give us
>> useful flexibility, or is
On 04/12/2015 12:00, Peter Maydell wrote:
> On 4 December 2015 at 07:30, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>>> On 7 September 2015 at 17:57, Markus Armbruster wrote:
Peter Maydell writes:
> On 7 September 2015 at 17:40, Markus Armbruster wrote:
>> Peter M
> I don't think we've ever said "we should transition away from HWADDR_*",
> but whether we should is an interesting question, which is why I asked.
> Does retaining the format macros to go with the typedef give us
> useful flexibility, or is it just confusing?
I think it's confusing, but not eno
On 16.11.2015 13:50, Xiao Guangrong wrote:
NVDIMM (A Non-Volatile Dual In-line Memory Module) is going to be supported
on Intel's platform.
Hi.
One question: do this mean, that your qemu emulated nvidimm - pmem
solution will work only on Intel host?
--
Best regards,
Vladimir
* now, @virtuo
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's impossible to change
Windows kernel.
Following is my idea to do DMA tracking.
Inject event to VF
On Thu, 3 Dec 2015, Jianzhong,Chang wrote:
> From: jianzhong,Chang
>
> Add pci = [ '$VF_BDF', '$VF_BDF', '$VF_BDF'] in
This is a bit confusing: it is not actually correct to assign the same
device, even an SR_IOV VF, multiple times, so these must be all
different. More like:
pci = [ '$VF_BDF1',
Hi Andrea,
On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote:
> On 05/14/2015 07:30 PM, Andrea Arcangeli wrote:
>> Add documentation.
>
> Hi Andrea,
>
> I do not recall... Did you write a man page also for this new system call?
No response to my last mail, so I'll try again... Did you
LEON3 allows the CASA instruction to be used from user space
if the ASI is set to 0xa (user data).
Signed-off-by: Alex Zuepke
---
target-sparc/translate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 41a3319..6344
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on ov
On 04/12/2015 15:59, Markus Armbruster wrote:
> My comment makes two claims: "wrong" and "dangerous".
>
> First "dangerous". You're making a non-local argument why it's not
> actually broken, and you might be right. If you are, it's just fragile,
> not broken. We could debate whether to call
On Thu, 3 Dec 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
>
> Previous patches have already
From: Gabriel Somlo
Make fw_cfg entries of type "file" available via sysfs. Entries
are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders
named after each entry's selector key. Filename, selector value,
and size read-only attributes are included for each entry. Also,
a "raw" attribute all
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
Acked-by: Rob Herring
Reviewed-by: Lasz
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
On Thu, 3 Dec 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings
On Thu, 3 Dec 2015, Ian Campbell wrote:
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 2cadd4f..8fbaf07 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -41,6 +41,7 @@ static inline void *xc_map_foreign_bulk(int xc_handle,
> uint
Instead of using offset macros and bit operations in a uint32_t
array, use the X86XSaveArea struct to perform the loading/saving
operations in kvm_put_xsave() and kvm_get_xsave().
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Use uint8_t pointers when loading/saving xmm, ymmh, zmmh,
ke
Add structs that define the layout of the xsave areas used by
Intel processors. Add some QEMU_BUILD_BUG_ON lines to ensure the
structs match the XSAVE_* macros in target-i386/kvm.c and the
offsets and sizes at target-i386/cpu.c:ext_save_areas.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
This doesn't introduce any change in the code, as the offsets and
struct sizes match what was present in the table. This can be
validated by the QEMU_BUILD_BUG_ON lines on target-i386/cpu.h,
which ensures the struct sizes and offsets match the existing
values in ext_save_area.
Signed-off-by: Eduar
target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
uses offset macros and bit manipulation to access the xsave area.
This series changes both to use C structs for those operations.
I still need to figure out a way to
Paolo Bonzini writes:
> On 04/12/2015 15:07, Markus Armbruster wrote:
>> We made it unavailable in commit 1910913 because its use of
>> drive_get_next() instead of a property. Commit 5ec911c replaced
>> drive_get_next() and made the device available, but the property isn't
>> quite right, and th
On Wed, Nov 18, 2015 at 10:20:14AM +0800, Huaitong Han wrote:
> Changes in v3:
> *Fix cpuid_7_0_ecx_feature_name error.
>
> Changes in v2:
> *Fix memcpy error for xsave state.
> *Fix TCG_7_0_ECX_FEATURES to 0.
> *Make subjects more readable.
>
> The protection-key feature provides an additional m
2015-12-04 22:20 GMT+09:00 Marc-André Lureau :
> Hi
>
> On Fri, Dec 4, 2015 at 4:52 AM, Tetsuya Mukawa wrote:
>> If virtio-net driver allocates memory in vishmem shared memory,
>
> s/vishmem/ivshmem
Thanks, I will fix it.
>
> How can virtio-net allocate memory in ivshmem memory bar?
>
> What's t
The patch adds Error ** parameter to load_vmstate call and fills error
inside. The caller after that properly reports error either through
monitor or via local stderr facility during VM start.
This helper will be useful too for qmp_loadvm implementation.
Signed-off-by: Denis V. Lunev
CC: Juan Qu
The patch also moves hmp_delvm implementation into hmp.c. This function
is just a simple wrapper now and does not have knowledge about
migration internals.
Signed-off-by: Denis V. Lunev
CC: Juan Quintela
CC: Amit Shah
CC: Markus Armbruster
CC: Eric Blake
---
hmp.c | 11 +
'name' attribute is made mandatory in distinction with HMP command.
The patch also moves hmp_savevm implementation into hmp.c. This function
is just a simple wrapper now and does not have knowledge about
migration internals.
Signed-off-by: Denis V. Lunev
CC: Juan Quintela
CC: Amit Shah
CC: Mar
Unfortunately load_vmstate has a return code (int) and this code is checked
in the other places. Thus we could not just rename it to qmp_loadvm as
returns void.
Signed-off-by: Denis V. Lunev
CC: Juan Quintela
CC: Amit Shah
CC: Markus Armbruster
CC: Eric Blake
---
migration/savevm.c | 12
EFI based VM with pflash storage for NVRAM could not be snapshoted as
libvirt configures storage as 'raw' and writable. OK, this is a libvirt
problem.
Another problem is that libvirt can not detect this failure at all
as it uses HMP for this operation. This create snapshot/delete snapshot
sequence
This would be useful in the next step when QMP version of this call will
be introduced.
Signed-off-by: Denis V. Lunev
Reviewed-by: Juan Quintela
CC: Amit Shah
CC: Markus Armbruster
CC: Eric Blake
---
migration/savevm.c | 38 +++---
1 file changed, 23 insertion
The Xen toolstack uses "vhd" to specify a disk in VHD format, however
the name of the driver in QEMU is "vpc". Replace "vhd" with "vpc", so
that QEMU can find the right driver to use for it.
Signed-off-by: Stefano Stabellini
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 267d8a8..3
On 04/12/2015 15:33, Denis V. Lunev wrote:
> On 12/02/2015 03:22 PM, Paolo Bonzini wrote:
>>
>> On 30/11/2015 17:22, Andrey Smetanin wrote:
>>> enum hv_message_type inside struct hv_message, hv_post_message
>>> is not size portable. Replace enum by u32.
>> It's only non-portable inside structs.
On 04/12/2015 15:07, Markus Armbruster wrote:
> We made it unavailable in commit 1910913 because its use of
> drive_get_next() instead of a property. Commit 5ec911c replaced
> drive_get_next() and made the device available, but the property isn't
> quite right, and the code dangerously ignores b
On 12/02/2015 03:22 PM, Paolo Bonzini wrote:
On 30/11/2015 17:22, Andrey Smetanin wrote:
enum hv_message_type inside struct hv_message, hv_post_message
is not size portable. Replace enum by u32.
It's only non-portable inside structs. Okay to apply just these:
@@ -172,7 +174,7 @@ union hv_mes
> On (Fri) 04 Dec 2015 [11:53:09], Liang Li wrote:
> > There are some flaws in qemu_put_compression_data, this patch tries to
> > fix it. Now it can be used by other code.
>
> Can you please write a better description here? What are the flaws?
> What is being fixed? What other users, and how is
> > There are some flaws in qemu_put_compression_data, this patch tries to
> > fix it. Now it can be used by other code.
> >
> > Signed-off-by: Liang Li
> > ---
> > migration/qemu-file.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/migration/qemu-file.c
On Mon, 16 Nov 2015 21:23:07 +0800
shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Here GPIO pin 3 is used for Power Button, add _E03 in ACPI DSDT table.
>
> Signed-off-by: Shannon Zhao
> Signed-off-by: Shannon Zhao
> Tested-by: Wei Huang
> ---
> hw/arm/virt-acpi-build.c | 13 ++
On Fri, Dec 04, 2015 at 02:24:41PM +0100, Igor Mammedov wrote:
> On Thu, 3 Dec 2015 15:16:21 -0200
> Eduardo Habkost wrote:
>
> > On Thu, Dec 03, 2015 at 04:19:19PM +0100, Igor Mammedov wrote:
> > > On Wed, 2 Dec 2015 20:22:45 -0200
> > > Eduardo Habkost wrote:
> > >
> > > > This series remove
We made it unavailable in commit 1910913 because its use of
drive_get_next() instead of a property. Commit 5ec911c replaced
drive_get_next() and made the device available, but the property isn't
quite right, and the code dangerously ignores blk_attach_dev()
failure. Disable it again before the pr
On 12/03/2015 10:53 AM, Didier Pallard wrote:
Hi,
I recently did some stress tests of a vhost-user interface using an UDP
traffic generator. Traffic generator was connected to 2 physical ports
that are in turn connected to 2 virtio ports through a linux bridge, VM
(running linux) doing routing t
> Hi
>
> We are in hard freeze. My understanding is that this are "optimizations" that
> can wait for 2.6:
> - my understanding from commit from message one and from quick look at
> the code is that this change is not needed for current users, is that
> correct?
> - we avoid a copy at the begi
This is doing a more complete test on setting cache modes both while
opening an image (i.e. in a -drive command line) and in reopen
situations. It checks that reopen can specify options for child nodes
and that cache modes are correctly inherited from parent nodes where
they are not specified.
Sig
This is a basic test for specifying cache modes for child nodes on the
command line. It doesn't take much time and works without O_DIRECT
support.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
tests/qemu-iotests/051 | 10 +++-
tests/qemu-iotests/051.out | 60 +
'node-name' and 'driver' should not be changed during a reopen
operation. It is, however, valid to specify them with the same value as
they already had.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
tests/qemu-iotests/133 | 90 ++
tests/qem
bs->options doesn't only contain options that the user explicitly
requested, but also option that were derived from flags, the filename or
inherited from the parent node.
For reopen, it is important to know the difference because reopening the
parent can change inherited values in child nodes, but
On 12/04/2015 02:19 AM, Miao Yan wrote:
> Macro VMW_SHPRN(...) is already defined vmxnet3_debug.h,
> so remove the duplication
>
> Signed-off-by: Miao Yan
> ---
> hw/net/vmware_utils.h | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Eric Blake
>
> diff --git a/hw/net
Just reopening the children (as block.c does now) is enough.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
---
block/blkdebug.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 48b0812..7132e2c 100644
--- a/bloc
Options are not actually inherited from the parent node yet, but this
commit lays the grounds for doing so.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
block.c | 52 ---
include/block/block_int.h | 3 ++-
2 files changed, 3
Specifying the cache mode for a driver without a medium is not a useful
thing to do: As long as there is no medium, the cache mode doesn't make
a difference, and once the 'change' command is used to insert a medium,
it ignores the old cache mode and makes the new medium use
cache=writethrough.
Lat
The next patch distinguishes options that were explicitly set and
options that were derived. bdrv_fill_option() added options of both
types: Options given by json: syntax should be counted as explicit, but
the rest is derived.
In preparation for the distinction, move json: parse to a separate
func
On Fri, Dec 04, 2015 at 11:15:48AM +0100, Cornelia Huck wrote:
> On Fri, 4 Dec 2015 10:06:58 +0800
> Jason Wang wrote:
>
> > The problem is for pci: without this patch, guest may always see modern
> > bar is "disable-modern=false". But with this patch, on an old kernel
> > that does not support V
If the child was defined in the same context (-drive argument or
blockdev-add QMP command) as its parent, a reopen of the parent should
work the same and allow changing options of the child.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
---
block.c | 12 +
This patch adds a QemuOpts for generic block layer options to
bdrv_reopen_prepare(). The only two options that currently exist
(node-name and driver) cannot be changed, so the only thing we do is
putting them right back into the QDict so that we check at the end that
they are indeed unchanged.
We
This adds the cache mode options to the QDict, so that they can be
specified for child nodes (e.g. backing.cache.direct=off).
The cache modes are not removed from the flags at this point; instead,
options and flags are kept in sync. If the user specifies both flags and
options, the options take pr
The code already special-cased "node-name", which is currently the only
option passed in the QDict that isn't driver-specific. Generalise the
code to take all general block layer options into consideration.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Max Reitz
Reviewed-by: Al
Creating an empty drive while specifying 'format' doesn't make sense.
The specified format driver would simply be ignored.
Make a set 'format' option an indication that a non-empty drive should
be created. This makes 'format' consistent with 'driver' and allows
using it with a block driver that do
Some drivers have nested options (e.g. blkdebug rule arrays), which
don't belong to a child node and shouldn't be removed. Don't remove all
options with "." in their name, but check for the complete prefixes of
actually existing child nodes.
Signed-off-by: Kevin Wolf
---
block.c
This is part three (or four, depending on whether you count the bdrv_swap
removal) of what I had sent earlier as "[PATCH 00/34] block: Cache mode for
children, reopen overhaul and more". Most of the patches were actually already
reviewed in v1.
This part contains the remaining functional changes t
For bs->file, using references to existing BDSes has been possible for a
while already. This patch enables the same for bs->backing.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
block.c | 48 +---
block/mirror.c| 2 +-
i
Instead of passing a separate drv argument to bdrv_open_common(), just
make sure that a "driver" option is set in the QDict. This also means
that a "driver" entry is consistently present in bs->options now.
This is another step towards keeping all options in the QDict (which is
the represenation o
In order to decide whether a blkdebug: filename can be produced or a
json: one is necessary, blkdebug checked whether bs->options had more
options than just "config", "x-image" or "image" (the latter including
nested options). That doesn't work well when generic block layer options
are present.
Th
qcow2 accepts a few driver-specific options that overlap semantically
(e.g. "overlap-check" is an alias of "overlap-check.template", and any
missing cache size option is derived from the given ones).
When bdrv_reopen() merges the set of updated options with left out
options that should be kept at
bdrv_replace_in_backing_chain() asserts that not both old and new
BlockDdriverState have a BlockBackend attached to them because both
would have to end up pointing to the new BDS and we don't support more
than one BB per BDS yet.
Before we can safely allow references to existing nodes as backing
f
1 - 100 of 148 matches
Mail list logo
