On Wed, May 11, 2016 at 02:40:30PM +0800, Peter Xu wrote:
> Recently I encountered issue when debugging Intel IOMMU IR codes,
> that interrupts are not working correctly with PCI bridges (reported
> by Radim). This patch fixes the problem. I assume requester ID
> should be the devfn on root PCI bus
Hi Peter,
On 2016/5/10 1:29, Peter Maydell wrote:
> Code review, testing, attempts to run guests other than Linux
> welcome (UEFI, anybody?)
I run a guest with UEFI firmware. It gets stuck when kernel boots:
[0.186331] Brought up 1 CPUs
[0.186613] SMP: Total of 1 processors activated.
[
> From: Alex Williamson
> Sent: Thursday, May 05, 2016 1:06 AM
> > > > +
> > > > + ret = remap_pfn_range(vma, virtaddr, pgoff, req_size, pg_prot);
> > >
> > > So not supporting validate_map_request() means that the user can
> > > directly mmap BARs of the host GPU and as shown below, we assum
When there are devices under PCI bridge (or bridges), PCI requester ID
should be the one that hooked on the root PCI bus, not the PCI device
itself.
Signed-off-by: Peter Xu
---
hw/pci/msi.c | 2 +-
hw/pci/pci.c | 9 +
include/hw/pci/pci.h | 2 ++
3 files changed, 12 inser
Recently I encountered issue when debugging Intel IOMMU IR codes,
that interrupts are not working correctly with PCI bridges (reported
by Radim). This patch fixes the problem. I assume requester ID
should be the devfn on root PCI bus (that's how I understand it
before, and also in guest kernel, IRT
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Thursday, May 05, 2016 8:57 PM
>
>
> On 5/5/2016 5:37 PM, Tian, Kevin wrote:
> >> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> >> Sent: Thursday, May 05, 2016 6:45 PM
> >>
> >>
> >> On 5/5/2016 2:36 PM, Tian, Kevin wrote:
>
Public bug reported:
Problem: after leaving a Windows VM that uses PCI passthrough (as we do
for gaming graphics cards, sound cards, and in my case, a USB card)
running for some amount of time between 1 and 2 hours (it's not
consistent with exactly how long), and for any amount of time longer
than
Hi, Alex
What do you think about the following solution?
1. Detect support for resume notification.
If host vfio driver does not have resume notifier flags,
Directly fail to boot up VM as with aer enabled.
2. Immediately notify the VM on error detected.
3. Stall any a
Now they are invalidated by the block layer, so it's not necessary to
do this in block drivers' implementations of .bdrv_invalidate_cache.
Signed-off-by: Fam Zheng
---
block/qcow2.c | 7 ---
block/qed.c| 6 --
block/quorum.c | 16
3 files changed, 29 deletions(-)
v2: Two passes inactivation. [Kevin]
For now we only consider bs->file chain. In fact this is incomplete. For
example, if qcow2 is a quorum child, we don't properly invalidate or inactivate
it. This series recurses into the subtrees in both bdrv_invalidate_cache_all
and bdrv_inactivate_all. This
Currently we only inactivate the top BDS. Actually bdrv_inactivate
should be the opposite of bdrv_invalidate_cache.
Recurse into the whole subtree instead.
Because a node may have multiple parents, and because once
BDRV_O_INACTIVE is set for a node, further writes are not allowed, we
cannot inter
Currently we only recurse to bs->file, which will miss the children in quorum
and VMDK.
Recurse into the whole subtree to avoid that.
Signed-off-by: Fam Zheng
---
block.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/block.c b/block.c
index d4939b4..f
On Tue, 05/10 10:33, Kevin Wolf wrote:
>
> Fair enough. My series didn't have a separate callback, but with yours
> that should be working.
>
> So is the semantics of .bdrv_inactivate() basically "bdrv_flush, and I
> really mean it"?
Yes.
>
> > > Maybe we need something like an "active referen
On Tue, 05/03 16:39, Eric Blake wrote:
> I noticed some inconsistencies in FUA handling while working
> with NBD, then Kevin pointed out that my initial attempt wasn't
> quite right for iscsi which also had problems, so this has
> expanded into a series rather than a single patch.
>
> I'm not sure
On Wed, 05/11 08:48, Fam Zheng wrote:
> racy problem. Any suggestion how this could be fixed?
Reading into the subthread I see the answer: the file-private locks look
promising. Will take a look at that! Thanks.
Fam
On Tue, 05/10 09:57, Daniel P. Berrange wrote:
> On Tue, May 10, 2016 at 10:50:40AM +0800, Fam Zheng wrote:
> > They are wrappers of POSIX fcntl file locking, with the additional
> > interception of open/close (through qemu_open and qemu_close) to offer a
> > better semantics that preserves the loc
For better performance, we can use RAMblock
directly stored in memory_region at present.
Signed-off-by: Gonglei
---
exec.c | 33 ++---
hw/misc/ivshmem.c | 8 +---
hw/virtio/vhost-user.c | 13 -
include/exec/ram_addr.h | 4 +---
On 05/02/2016 06:33 AM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov
> ---
> hw/acpi/cpu.c | 83
> +++
> hw/acpi/ich9.c| 3 ++
> hw/acpi/piix4.c | 3 ++
> include/hw/acpi/cpu.h | 4 +++
> qapi-schema.json | 2 +
On Sparc, gcc implicitly passes --relax to the linker, but -r is
incompatible with this. Therefore, if --no-relax is supported, it should
be passed to the linker.
Signed-off-by: James Clarke
---
configure | 13 +
rules.mak | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
di
On Tue, May 10, 2016 at 04:41:27PM +0100, Alex Bligh wrote:
On 10 May 2016, at 16:29, Eric Blake wrote:
So the kernel is currently one of the clients that does NOT honor block
sizes, and as such, servers should be prepared for ANY size up to
UINT_MAX (other than DoS handling).
Interesting f
This affects both binary editions (for instance "qemu-system-i386.exe"
AND "qemu-system-i386w.exe")
dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more
Dump of file C:\Program Files\qemu\qemu-system-i386.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine
This affects both binary editions (for instance "qemu-system-i386.exe"
AND "qemu-system-i386w.exe")
dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more
Dump of file C:\Program Files\qemu\qemu-system-i386.exe
PE signature found
File Type: EXECUTABLE IMAGE
4.00 operating system version
5.
On Fri, May 06, 2016 at 11:42:45AM +0200, Juergen Gross wrote:
> Add a Xenstore directory for each supported pv backend. This will allow
> Xen tools to decide which backend type to use in case there are
> multiple possibilities.
>
> The information is added under
> /local/domain//device-model//bac
On 05/06/2016 02:45 AM, Quentin Casasnovas wrote:
> When running fstrim on a filesystem mounted through qemu-nbd with
> --discard=on, fstrim would fail with I/O errors:
>
> $ fstrim /k/spl/ice/
> fstrim: /k/spl/ice/: FITRIM ioctl failed: Input/output error
>
> and qemu-nbd was spitting these:
On Mon, May 02, 2016 at 02:33:32PM +0200, Igor Mammedov wrote:
> Machine types before 2.7 have legacy CPU hotplug
> enabled by defaut to not regress existing setups
> where it's always enabled.
>
> But since 2.7 CPU hotplug is disabled y default
> and requires explicit enabling using 'cpu-hotplug'
On Mon, May 02, 2016 at 02:33:29PM +0200, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov
If a machine class simply doesn't support CPU hotplug at all, is
silently ignoring "cpu-hotplug=on" the right thing to do?
Shouldn't we exit with an error if the machine class doesn't
support CPU hotplu
Hi Perter,
probalby ... i found something wrongs inside my ppc64 library , im clearing and
reinstall the glib . report it soon
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579565
Title:
ERROR:
Yes Fixed guys.
configure reply right . can close this bug , that was not a qemu bug.
** Changed in: qemu
Status: Fix Committed => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579565
On 05/10/2016 10:33 AM, Quentin Casasnovas wrote:
> Looks like there's an easier way:
>
> $ qemu-img create -f qcow2 foo.qcow2 10G
> $ qemu-nbd --discard=on -c /dev/nbd0 foo.qcow2
> $ mkfs.ext4 /dev/nbd0
> mke2fs 1.42.13 (17-May-2015)
> Discarding device blocks: failed - Input/output error
On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote:
> on old machine types CPU hotplug was uncondtionally
> enabled since it was introduced, consuming IO ports
> and providing AML regardles of whether it was actually
> in use or not. Keep it so for 2.6 and older machines.
>
> New machin
On Mon, May 02, 2016 at 02:33:20PM +0200, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov
Reviewed-by: Eduardo Habkost
--
Eduardo
On Mon, May 02, 2016 at 02:33:19PM +0200, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov
As the property is useless if no code is reading
s->pm.cpu_hotplug_legacy. What about squashing patches 10/42 and
12/42 together?
--
Eduardo
On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote:
> I looked at a dozen Intel CPU that have this CPUID and all of them
> always had Core offset as 1 (a wasted bit when hyperthreading is
> disabled) and Package offset at least 4 (wasted bits at <= 4 cores).
>
> QEMU uses more compact ID
I think Daniel is right -- your glib headers are broken, and we just
weren't diagnosing it before. You need to fix your glib install.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579565
Title:
ER
rc5 same issue
./configure
ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
You probably need to set PKG_CONFIG_LIBDIR
to point to the right pkg-config files for your
build target
thanks
--
You received this bug notification because you are a member of qemu-
devel-m
On 10/05/16 19:34, Richard Henderson wrote:
> On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
>> From: Sergey Fedorov
>>
>> Simplify cpu_exec() by extracting interrupt handling code outside of
>> cpu_exec() into a new static inline function cpu_handle_interrupt().
>>
>> Signed-off-by: Sergey Fedorov
On 10/05/16 19:21, Richard Henderson wrote:
> On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
>> From: Sergey Fedorov
>>
>> Simplify cpu_exec() by extracting exception handling code out of
>> cpu_exec() into a new static inline function cpu_handle_exception().
>> Also make cpu_handle_debug_exception
On 10/05/16 19:13, Richard Henderson wrote:
> On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
>> +#if defined(TARGET_I386) && !defined(CONFIG_USER_ONLY)
>> +X86CPU *x86_cpu = X86_CPU(cpu);
>> +
>> +if ((cpu->interrupt_request & CPU_INTERRUPT_POLL)
>> +&& replay_interrupt()
On 05/10/16 19:36, Richard W.M. Jones wrote:
> On Tue, May 10, 2016 at 07:24:28PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 09/05/2016 18:48, Richard W.M. Jones wrote:
>>>
>>> Of course we're well outside any standards here. Can we tell clang
>>> users to use the GCC/pre-compiled option ROMs :-? An
On Tue, May 10, 2016 at 3:36 AM, Edgar E. Iglesias
wrote:
> On Tue, May 10, 2016 at 09:09:55AM +0100, Peter Maydell wrote:
>> On 10 May 2016 at 01:16, Alistair Francis
>> wrote:
>> > It is actually a u-boot problem. I originally just assumed it was a
>> > Linux problem, but it happens before u-b
On Tue, May 10, 2016 at 1:09 AM, Peter Maydell wrote:
> On 10 May 2016 at 01:16, Alistair Francis wrote:
>> It is actually a u-boot problem. I originally just assumed it was a
>> Linux problem, but it happens before u-boot hands off to Linux.
>
> OK, that makes sense. u-boot tends to be a bit low
Hi
- Original Message -
> Hi,
>
> Just to let you know that as a client, it need to add the reconnect
> ability, as the QEMU (as the server) may restart as well. Well, I'm
> thinking that you may think it's an example bridge only, so, let it
> be simple. Then I'm sorry for the noise.
Tha
** Description changed:
When running on Windows error messages before the UI is started are not
showing up.
For example when I run:
qemu-system-i386.exe -L /mingw32/etc/qemu/ -m 20G
It should display "ram size too large", according to gdb:
Breakpoint 1, error_report (fmt=fm
On 10/05/2016 17:38, Alex Bligh wrote:
> > and are at the
> > mercy of however the kernel currently decides to split large requests).
>
> I am surprised TRIM doesn't get broken up the same way READ and WRITE
> do.
The payload of TRIM has constant size, so it makes sense to do that.
The kernel t
On Tue, May 10, 2016 at 07:24:28PM +0200, Paolo Bonzini wrote:
>
>
> On 09/05/2016 18:48, Richard W.M. Jones wrote:
> >
> > Of course we're well outside any standards here. Can we tell clang
> > users to use the GCC/pre-compiled option ROMs :-? Any other ideas? I
> > don't think I've missed a
On Tue, May 10, 2016 at 17:19:51 +0200, Igor Mammedov wrote:
> On Fri, 6 May 2016 15:11:31 -0300
> Eduardo Habkost wrote:
>
> > This makes the feature name tables in feature_word_info all match
> > the actual QOM property names we use.
> >
> > This will make the command-line interface more cons
On 09/05/2016 18:48, Richard W.M. Jones wrote:
>
> Of course we're well outside any standards here. Can we tell clang
> users to use the GCC/pre-compiled option ROMs :-? Any other ideas? I
> don't think I've missed a flag (GCC has -fno-toplevel-reorder, but
> clang 3.8 doesn't ...)
I guess t
On 09/05/2016 23:37, Richard W.M. Jones wrote:
> FWIW the response from the LLVM developers:
>
> https://llvm.org/bugs/show_bug.cgi?id=27688
Why the heck are they saying that -fno-toplevel-reorder is "gone" (or
deprecated in the duplicate PR)?
Paolo
Hi,
Just to let you know that as a client, it need to add the reconnect
ability, as the QEMU (as the server) may restart as well. Well, I'm
thinking that you may think it's an example bridge only, so, let it
be simple. Then I'm sorry for the noise.
--yliu
On Tue, May 10, 2016 at 06:03:52
On 10/05/2016 17:36, Michael S. Tsirkin wrote:
>> > Can you explain why requiring the user to specify -device in a sane
>> > order isn't good enough?
> Because it requires knowledge about the hardware.
> For example, how do users know that iommu must come before the devices?
> They don't.
Could
Hi Marc,
I was also thinking we should do it in this way first. That simplfies
things. So, feel free to add:
Tested-by: Yuanhan Liu
Reviewed-by: Yuanhan Liu
(well, I didn't review the test case carefully).
Thanks.
--yliu
On Tue, May 10, 2016 at 06:03:50PM +0200, marcandre.lur...@red
On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
From: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 12
1 file changed, 12 deletions(-)
Reviewed-by: Richard Henderson
r~
On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
From: Sergey Fedorov
Simplify cpu_exec() by extracting TB execution code outside of
cpu_exec() into a new static inline function cpu_loop_exec_tb().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 119 +++
On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
From: Sergey Fedorov
Simplify cpu_exec() by extracting interrupt handling code outside of
cpu_exec() into a new static inline function cpu_handle_interrupt().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 132 +
On Tue, May 10, 2016 at 05:23:21PM +0100, Alex Bligh wrote:
>
> On 10 May 2016, at 17:04, Quentin Casasnovas
> wrote:
>
> > Alright, I assumed by 'length of an NBD request', the specification was
> > talking about the length of.. well, the request as opposed to whatever is
> > in the length fie
On 10/05/2016 11:59, Stefan Hajnoczi wrote:
> > I still dream of having qtests written in Python; I agree that for now
> > this makes sense.
>
> Is there any particular Python feature that you miss?
I would like to use QMP more and to autodiscover buses (so that every
SCSI test can be run on bo
On Tue, May 10, 2016 at 05:54:44PM +0200, Quentin Casasnovas wrote:
> On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote:
> > On 05/10/2016 09:41 AM, Alex Bligh wrote:
> > >
> > > On 10 May 2016, at 16:29, Eric Blake wrote:
> > >
> > >> So the kernel is currently one of the clients that
Hi
- Original Message -
> On Tue, May 10, 2016 at 06:03:50PM +0200, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > Hi,
> >
> > In a previous series "RFCv2: vhost-user: shutdown and reconnection", I
> > proposed to add a new slave request to handle graceful shutdo
On 10 May 2016, at 17:04, Quentin Casasnovas
wrote:
> Alright, I assumed by 'length of an NBD request', the specification was
> talking about the length of.. well, the request as opposed to whatever is
> in the length field of the request header.
With NBD_CMD_TRIM the length in the header fiel
On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
From: Sergey Fedorov
Simplify cpu_exec() by extracting exception handling code out of
cpu_exec() into a new static inline function cpu_handle_exception().
Also make cpu_handle_debug_exception() inline as it is used only once.
If it's used only onc
On Tue, May 10, 2016 at 06:03:50PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Hi,
>
> In a previous series "RFCv2: vhost-user: shutdown and reconnection", I
> proposed to add a new slave request to handle graceful shutdown, for
> both qemu configuration, server or cl
From: Tetsuya Mukawa
Current QEMU cannot detect vhost-user backend disconnection. The
patch adds ability to know it.
To know disconnection, add watcher to detect G_IO_HUP event. When
G_IO_HUP event is detected, the disconnected socket will be read
to cause a CHR_EVENT_CLOSED.
Signed-off-by: Tets
On 05/10/2016 05:46 AM, Sergey Fedorov wrote:
+#if defined(TARGET_I386) && !defined(CONFIG_USER_ONLY)
+X86CPU *x86_cpu = X86_CPU(cpu);
+
+if ((cpu->interrupt_request & CPU_INTERRUPT_POLL)
+&& replay_interrupt()) {
+apic_poll_irq(x86_cpu->apic_state);
Sinc
Currently all block tests use the traditional syntax for images
just specifying a filename. To support the LUKS driver without
resorting to JSON, the tests need to be able to use the new
--image-opts argument to qemu-img and qemu-io.
This introduces a new env variable IMGOPTSSYNTAX. If this is
set
This adds support for testing the LUKS driver with the block
I/O test framework.
cd tests/qemu-io-tests
./check -luks
A handful of test cases are modified to work with luks
- 004 - whitelist luks format
- 012 - use TEST_IMG_FILE instead of TEST_IMG for file ops
- 048 - use TEST_IMG_FILE
This series contains the 3 test suite patches that had to be dropped
from the v6 series during merge with the block tree:
v6: https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg04935.html
v7: https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg06687.html
v8: https://lists.gnu.org/arc
The LUKS block driver tests will require the ability to specify
encryption secrets with block devices. This requires using the
--object argument to qemu-img/qemu-io to create a 'secret'
object.
When the IMGKEYSECRET env variable is set, it provides the
password to be associated with a secret calle
From: Marc-André Lureau
The initial vhost-user connection sets the features to be negotiated
with the driver. Renegotiation isn't possible without device reset.
To handle reconnection of vhost-user backend, ensure the same set of
features are provided, and reuse already acked features.
Signed-o
From: Marc-André Lureau
Do not crash when backend is not present while enabling the ring. A
following patch will save the enabled state so it can be restored once
the backend is started.
Signed-off-by: Marc-André Lureau
---
hw/net/vhost_net.c | 7 ++-
1 file changed, 6 insertions(+), 1 del
From: Marc-André Lureau
If the backend failed to start (for example feature negociation failed),
do not exit, but disconnect the char device instead. Slightly more
robust for reconnect case.
Signed-off-by: Marc-André Lureau
---
net/vhost-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 delet
From: Marc-André Lureau
This is a simple reconnect test, that simply checks if vhost-user
reconnection is possible and restore the state. A more complete test
would actually manipulate and check the ring contents (such extended
testing would benefit from the libvhost-user proposed in QEMU list to
From: Marc-André Lureau
A driver may change the vring enable state at run time but vhost-user
backend may not be present (a contrived example is when the backend is
disconnected and the device is reconfigured after driver rebinding)
Restore the vring state when the vhost-user backend is started,
From: Tetsuya Mukawa
The patch introduces qemu_chr_disconnect(). The function is used for
closing a fd accepted by listen fd. Though we already have qemu_chr_delete(),
but it closes not only accepted fd but also listen fd. This new function
is used when we still want to keep listen fd.
Signed-of
From: Marc-André Lureau
If -c is specified, vubr will try to connect to the socket instead of
listening for connections.
Signed-off-by: Marc-André Lureau
---
tests/vhost-user-bridge.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/t
From: Marc-André Lureau
Do not overwrite x86-64 tests, re-enable vhost-user-test.
Signed-off-by: Marc-André Lureau
---
tests/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile b/tests/Makefile
index 9194f18..50a99f8 100644
--- a/tests/Makefile
+++ b/tes
From: Marc-André Lureau
This patch is a similar solution to what Yuanhan Liu/Huawei Xie have
suggested for DPDK. When vubr quits (killed or crashed), a restart of
vubr would get stale vring base from QEMU. That would break the kernel
virtio net completely, making it non-work any more, unless a dr
From: Marc-André Lureau
Hi,
In a previous series "RFCv2: vhost-user: shutdown and reconnection", I
proposed to add a new slave request to handle graceful shutdown, for
both qemu configuration, server or client, while keeping the guest
running with link down status.
However, for the simple case
On Tue, May 10, 2016 at 03:52:27PM +0800, Jike Song wrote:
> On 05/05/2016 05:27 PM, Tian, Kevin wrote:
> >> From: Song, Jike
> >>
> >> IIUC, an api-only domain is a VFIO domain *without* underlying IOMMU
> >> hardware. It just, as you said in another mail, "rather than
> >> programming them into a
On Tue, May 10, 2016 at 04:49:57PM +0100, Alex Bligh wrote:
>
> On 10 May 2016, at 16:45, Quentin Casasnovas
> wrote:
>
> > I'm by no mean an expert in this, but why would the kernel break up those
> > TRIM commands? After all, breaking things up makes sense when the length
> > of the request
On 10 May 2016, at 16:46, Eric Blake wrote:
> Does anyone have an easy way to cause the kernel to request a trim
> operation that large on a > 4G export? I'm not familiar enough with
> EXT4 operation to know what file system operations you can run to
> ultimately indirectly create a file system
On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote:
> On 05/10/2016 09:41 AM, Alex Bligh wrote:
> >
> > On 10 May 2016, at 16:29, Eric Blake wrote:
> >
> >> So the kernel is currently one of the clients that does NOT honor block
> >> sizes, and as such, servers should be prepared for ANY
On 10 May 2016, at 16:45, Quentin Casasnovas
wrote:
> I'm by no mean an expert in this, but why would the kernel break up those
> TRIM commands? After all, breaking things up makes sense when the length
> of the request is big, not that much when it only contains the request
> header, which is
From: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 12
1 file changed, 12 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 60f565074618..2526df0e3e40 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -571,10 +571,6 @@ static inline
On 10/05/16 18:46, Sergey Fedorov wrote:
> From: Sergey Fedorov
>
> cpu_exec() was a huge function also sprinkled with some preprocessor
> directives. It was hard to read and see the main loop crowded by all
> this code. Restructure cpu_exec() by moving its conceptual parts into
> separate static
The -machine kvm_shadow_mem option takes a size in bytes; say
so explicitly in its documentation.
Signed-off-by: Peter Maydell
Reported-by: Tobi (github.com/tobimensch)
---
qemu-options.hx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index
From: Sergey Fedorov
Simplify cpu_exec() by extracting CPU halt state handling code out of
cpu_exec() into a new static inline function cpu_handle_halt().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 39 +--
1 file changed, 2
From: Sergey Fedorov
Simplify cpu_exec() by extracting TB execution code outside of
cpu_exec() into a new static inline function cpu_loop_exec_tb().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 119 +
From: Sergey Fedorov
Simplify cpu_exec() by extracting interrupt handling code outside of
cpu_exec() into a new static inline function cpu_handle_interrupt().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu-exec.c | 132 -
From: Sergey Fedorov
Simplify cpu_exec() by extracting exception handling code out of
cpu_exec() into a new static inline function cpu_handle_exception().
Also make cpu_handle_debug_exception() inline as it is used only once.
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
---
cpu
From: Sergey Fedorov
cpu_exec() was a huge function also sprinkled with some preprocessor
directives. It was hard to read and see the main loop crowded by all
this code. Restructure cpu_exec() by moving its conceptual parts into
separate static inline functions. That makes it possible to see the
On 05/10/2016 09:41 AM, Alex Bligh wrote:
>
> On 10 May 2016, at 16:29, Eric Blake wrote:
>
>> So the kernel is currently one of the clients that does NOT honor block
>> sizes, and as such, servers should be prepared for ANY size up to
>> UINT_MAX (other than DoS handling).
>
> Interesting foll
On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote:
> Eric,
>
> On 10 May 2016, at 16:29, Eric Blake wrote:
> >>> Maybe we should revisit that in the spec, and/or advertise yet another
> >>> block size (since the maximum size for a trim and/or write_zeroes
> >>> request may indeed be diff
On 10 May 2016, at 16:29, Eric Blake wrote:
> So the kernel is currently one of the clients that does NOT honor block
> sizes, and as such, servers should be prepared for ANY size up to
> UINT_MAX (other than DoS handling).
Interesting followup question:
If the kernel does not fragment TRIM re
On Sat, Apr 09, 2016 at 05:37:45PM -0300, Eduardo Habkost wrote:
> Instead of relying on x86_cpudef_setup() calling
> qemu_hw_version(), just make old machines set model-id explicitly
> on compat_props for qemu64, qemu32, and athlon. This will allow
> us to eliminate x86_cpudef_setup() later.
>
>
Eric,
On 10 May 2016, at 16:29, Eric Blake wrote:
>>> Maybe we should revisit that in the spec, and/or advertise yet another
>>> block size (since the maximum size for a trim and/or write_zeroes
>>> request may indeed be different than the maximum size for a read/write).
>>
>> I think it's up to
On Tue, May 10, 2016 at 10:28:43AM +0200, Markus Armbruster wrote:
> Marcel Apfelbaum writes:
>
> > This series aims to allow more devices to be used with '-device'
> > by sorting the devices based on a predefined creation order flag
> > before creating them.
> >
> > Devices like IOMMU need to be
On 05/10/2016 09:08 AM, Alex Bligh wrote:
> Eric,
>
>> Hmm. The current wording of the experimental block size additions does
>> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the
>> maximum NBD_CMD_WRITE:
>> https://github.com/yoe/nbd/blob/extension-info/doc/proto.md#block-si
On Tue, May 10, 2016 at 03:55:11PM +0200, Paolo Bonzini wrote:
> On 19/04/2016 21:55, Eduardo Habkost wrote:
> > * Clean up the graphics initialization code to reduce the
> > number of #ifdefs;
> > * Remove the display_type == DT_NOGRAPHIC checks from hardware
> > emulation code;
> > * Make the
On Tue, 23 Feb 2016 10:22:33 -0500
"Kevin O'Connor" wrote:
> On Tue, Feb 16, 2016 at 02:39:27PM -0700, Alex Williamson wrote:
> > QEMU provides two fw_cfg files to support IGD. The first holds the
> > OpRegion data which holds the Video BIOS Table (VBT). This needs to
> > be copied into reserve
On Fri, 6 May 2016 15:11:31 -0300
Eduardo Habkost wrote:
> This makes the feature name tables in feature_word_info all match
> the actual QOM property names we use.
>
> This will make the command-line interface more consistent,
> allowing the QOM property names to be used as "-cpu" arguments
>
1 - 100 of 210 matches
Mail list logo
