Eric Blake writes:
> On 9/21/18 9:10 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> [adding Markus, because of an interesting observation about
>>> --image-opts vs. JSON null - search for [1] below]
>>
>> There are four instances of [1], and my eyes glazed over before I
>> reached
Hi all,
I am trying to debug why NoVNC will not connect to qemu 2.12.1 via
websockets when TLS is enabled. When enabling debugging on the qemu side, I
get the following error when enabling websockets & tls using
"websocket,tls,x509=/etc/pki/xen"
Handshake failed TLS handshake failed: A
On Fri, Aug 31, 2018 at 6:32 AM Pankaj Gupta wrote:
>
> This patch adds virtio-pmem driver for KVM guest.
>
> Guest reads the persistent memory range information from
> Qemu over VIRTIO and registers it on nvdimm_bus. It also
> creates a nd_region object with the persistent memory
> range
On Fri, Aug 31, 2018 at 6:31 AM Pankaj Gupta wrote:
>
> This patch moves nd_region definition to common header
> include/linux/nd.h file. This is required for flush callback
> support for both virtio-pmem & pmem driver.
>
> Signed-off-by: Pankaj Gupta
> ---
> drivers/nvdimm/nd.h | 39
On Fri, Aug 31, 2018 at 6:32 AM Pankaj Gupta wrote:
>
> This patch adds functionality to perform flush from guest
> to host over VIRTIO. We are registering a callback based
> on 'nd_region' type. virtio_pmem driver requires this special
> flush function. For rest of the region types we are
Hi Eric,
Thanks for looking at this.
I looked at the nbd/server.c code and couldn't see how it could send a
NBD_REPLY_TYPE_NONE packet without setting the NBD_REPLY_FLAG_DONE bit.
The only place NBD_REPLY_TYPE_NONE is set is on line 1603:
set_be_chunk(, NBD_REPLY_FLAG_DONE,
On 9/21/18 11:42 AM, Matthew Schumacher wrote:
Public bug reported:
Qemu version on both sides: 2.12.1
Host A Linux: 4.9.76
Host B Linux: 4.14.67
While calling from Host A:
virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource
--persistent --verbose --copy-storage-all
We're not being consistent about this. If it's in use by an operation,
the user should not be able to change the behavior of that bitmap.
Signed-off-by: John Snow
---
blockdev.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/blockdev.c b/blockdev.c
If the bitmap is locked, we shouldn't touch it.
Signed-off-by: John Snow
---
blockdev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 651c50d1fa..1f03db0c3c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3435,10 +3435,10 @@ static BlockJob
Like frozen, "qmp locked" bitmaps must not be modified by the user.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 1 +
blockdev.c | 4
2 files changed, 5 insertions(+)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 5c8a7bbf6f..216baec388 100644
---
Instead of both frozen and qmp_locked checks, wrap it into one check.
frozen implies the bitmap is split in two (for backup), and shouldn't
be modified. qmp_locked implies it's being used by another operation,
like being exported over NBD. In both cases it means we shouldn't allow
the user to
Similarly to merge, it's OK to allow clear operations on disabled
bitmaps, as this condition only means that they are not recording
new writes. We are free to clear it if the user requests it.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 1 -
blockdev.c | 8
2 files
This builds on the previous standalone patch I sent and audits
the permissions we check for other QMP operations on bitmaps.
This should make it more consistent overall, but it's not
complete and I'm heading out for a long weekend, but I wanted
them on the list.
I think I should reorder the
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their recording of live, new
information. It does not prohibit them from manual writes at the behest
of the user, as is the case for merge operations.
Reported-by: Eric Blake
Signed-off-by:
Tested with Qemu 3.0.0 and this still happens.
Also tested with kernel 4.9.128 on one side and 4.9.76 on the other
thinking it might be a kernel 4.14 issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 9/20/18 7:07 PM, Philippe Mathieu-Daudé wrote:
> On 9/21/18 12:06 AM, Eduardo Habkost wrote:
>> On Thu, Sep 20, 2018 at 11:18:46PM +0200, Philippe Mathieu-Daudé wrote:
>>> On 9/20/18 10:14 PM, Eduardo Habkost wrote:
On Thu, Sep 20, 2018 at 04:00:27PM -0400, Cleber Rosa wrote:
> On
On 9/21/18 12:59 PM, Eduardo Habkost wrote:
> On Fri, Sep 21, 2018 at 03:34:02PM +0200, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>>
>>> On Fri, Sep 21, 2018 at 08:36:22AM +0200, Markus Armbruster wrote:
Eduardo Habkost writes:
> On Thu, Sep 20, 2018 at 11:19:56AM
On 9/20/18 5:18 PM, Philippe Mathieu-Daudé wrote:
> On 9/20/18 10:14 PM, Eduardo Habkost wrote:
>> On Thu, Sep 20, 2018 at 04:00:27PM -0400, Cleber Rosa wrote:
>>> On 9/20/18 2:58 PM, Eduardo Habkost wrote:
On Thu, Sep 20, 2018 at 11:19:56AM -0400, Cleber Rosa wrote:
> The acceptance
On 9/20/18 7:29 PM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
>
> On 9/20/18 5:19 PM, Cleber Rosa wrote:
>> A number of QEMU tests are written in Python, and may benefit
>> from an untainted Python venv.
>>
>> By using make rules, tests that depend on specific Python libs
>> can set that rule
On Fri, Sep 21, 2018 at 09:30:26AM +0200, Maxime Coquelin wrote:
>
>
> On 09/21/2018 04:33 AM, Jason Wang wrote:
> >
> >
> > On 2018年09月21日 04:39, Maxime Coquelin wrote:
> > > Hi Wei, Jason,
> > >
> > > On 06/19/2018 09:53 AM, Wei Xu wrote:
> > > > On Wed, Jun 06, 2018 at 11:48:19AM +0800,
On 09/21/18 17:43, Kashyap Chamarthy wrote:
> Hi folks,
>
> As Markus pointed out in this 'qemu-devel' thread[1],
> backends/rng-random.c uses '/dev/random' in TYPE_RNG_RANDOM's
> instance_init() method:
>
> [...]
> static void rng_random_init(Object *obj)
> {
> RngRandom *s
On 09/21/18 19:20, Michael S. Tsirkin wrote:
> On Fri, Sep 21, 2018 at 06:01:30PM +0300, Marcel Apfelbaum wrote:
>> On 09/20/2018 05:49 PM, Laszlo Ersek wrote:
>>> Now, there's another complication, obviously -- machine type compat. In
>>> commit 9fa99d2519cb, we added the "pci_hole64_fix" compat
On 09/21/18 17:01, Marcel Apfelbaum wrote:
> On 09/20/2018 05:49 PM, Laszlo Ersek wrote:
> I had to read this mail a few times...
Sorry :)
>> Now consider the following scenario:
>>
>> - the firmware programs some BARs with 64-bit addresses such that the
>>aperture that we deduce starts at
Am 21.09.2018 um 19:01 hat Eric Blake geschrieben:
> On 9/20/18 11:19 AM, Kevin Wolf wrote:
> > For the block job drain test, don't only test draining the source and
> > the target node, but create a backing chain for the source
> > (source_backing <- source <- source_overlay) and test draining
The upper limit on the L2 cache size is increased from 1 MB to 32 MB
on Linux platforms, and to 8 MB on other platforms (this difference is
caused by the ability to set intervals for cache cleaning on Linux
platforms only).
This is done in order to allow default full coverage with the L2 cache
Sufficient L2 cache can noticeably improve the performance when using
large images with frequent I/O.
Previously, unless 'cache-size' was specified and was large enough, the
L2 cache was set to a certain size without taking the virtual image size
into account.
Now, the L2 cache assignment is
The refcount cache size does not need to be set to its minimum value in
read_cache_sizes(), as it is set to at least its minimum value in
qcow2_update_options_prepare().
Signed-off-by: Leonid Bloch
Reviewed-by: Alberto Garcia
---
block/qcow2.c | 5 ++---
1 file changed, 2 insertions(+), 3
Signed-off-by: Leonid Bloch
Reviewed-by: Alberto Garcia
---
block/qcow2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index f885afa0ed..ffb4a9e4a1 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1324,7 +1324,7 @@ static int
Signed-off-by: Leonid Bloch
Reviewed-by: Alberto Garcia
---
block/qcow2.c | 2 +-
block/qcow2.h | 9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index ec9e6238a0..67cc82f0b9 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -830,7
Signed-off-by: Leonid Bloch
---
docs/qcow2-cache.txt | 20 +---
qemu-options.hx | 9 ++---
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt
index 8a09a5cc5f..013991e21c 100644
--- a/docs/qcow2-cache.txt
+++
The default cache-clean-interval is set to 10 minutes, in order to lower
the overhead of the qcow2 caches (before the default was 0, i.e.
disabled).
* For non-Linux platforms the default is kept at 0, because
cache-clean-interval is not supported there yet.
Signed-off-by: Leonid Bloch
---
Adding a lookup table for the powers of two, with the appropriate size
prefixes. This is needed when a size has to be stringified, in which
case something like '(1 * KiB)' would become a literal '(1 * (1L << 10))'
string. Powers of two are used very often for sizes, so such a table
will also make
The caches are now recalculated upon image resizing. This is done
because the new default behavior of assigning L2 cache relatively to
the image size, implies that the cache will be adapted accordingly
after an image resize.
Signed-off-by: Leonid Bloch
Reviewed-by: Alberto Garcia
---
This series makes the qcow2 L2 cache assignment aware of the image size,
with the intention for it to cover the entire image. The importance of
this change is in noticeable performance improvement, especially with
heavy random I/O. The memory overhead is not big in most cases, as only
1 MB of
On Wed, Sep 12, 2018 at 04:55:30PM +0400, Marc-André Lureau wrote:
> The following patch is going to add compatiblity parameters.
>
> Signed-off-by: Marc-André Lureau
For pc bits:
Reviewed-by: Michael S. Tsirkin
> ---
> include/hw/i386/pc.h | 5 -
> hw/i386/pc_piix.c| 15
On Fri, Sep 21, 2018 at 06:01:30PM +0300, Marcel Apfelbaum wrote:
>
>
> On 09/20/2018 05:49 PM, Laszlo Ersek wrote:
> > Hi Marcel,
>
> Hi Laszlo,
> I had to read this mail a few times...
>
> >
> > this email should actually be an RFC patch. But RFC patches tend to turn
> > into real PATCHes
* David Hildenbrand (da...@redhat.com) wrote:
> On 21/09/2018 18:55, Dr. David Alan Gilbert wrote:
> > * David Hildenbrand (da...@redhat.com) wrote:
> >> On 21/09/2018 18:00, Dr. David Alan Gilbert wrote:
> >>> * David Hildenbrand (da...@redhat.com) wrote:
> Compile virtio-pmem for x86 and
On 21/09/2018 18:55, Dr. David Alan Gilbert wrote:
> * David Hildenbrand (da...@redhat.com) wrote:
>> On 21/09/2018 18:00, Dr. David Alan Gilbert wrote:
>>> * David Hildenbrand (da...@redhat.com) wrote:
Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
(memory-device
On Wed, Sep 19, 2018 at 17:23:29 -0700, Peter Maydell wrote:
> On 19 September 2018 at 17:19, Alex Bennée wrote:
> >> An additional improvement that I have thought of is to get rid
> >> of memset(-1) altogether. Instead, we'd store addresses in the TLB
> >> as $real_address+1, so that 0xff..ff is
On Fri, Sep 21, 2018 at 03:34:02PM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Fri, Sep 21, 2018 at 08:36:22AM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Thu, Sep 20, 2018 at 11:19:56AM -0400, Cleber Rosa wrote:
[...]
> >> >>
* David Hildenbrand (da...@redhat.com) wrote:
> On 21/09/2018 18:00, Dr. David Alan Gilbert wrote:
> > * David Hildenbrand (da...@redhat.com) wrote:
> >> Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
> >> (memory-device part) from our pc machine hotplug handler.
> >>
> >>
On 9/20/18 11:19 AM, Kevin Wolf wrote:
For the block job drain test, don't only test draining the source and
the target node, but create a backing chain for the source
(source_backing <- source <- source_overlay) and test draining each of
the nodes in it.
When using iothreads, the source node
Public bug reported:
Qemu version on both sides: 2.12.1
Host A Linux: 4.9.76
Host B Linux: 4.14.67
While calling from Host A:
virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource
--persistent --verbose --copy-storage-all
I get a qemu crash with:
2018-09-21
On 9/20/18 11:19 AM, Kevin Wolf wrote:
When draining a block node, we recurse to its parent and for subtree
drains also to its children. A single AIO_WAIT_WHILE() is then used to
wait for bdrv_drain_poll() to become true, which depends on all of the
nodes we recursed to. However, if the
On 9/20/18 11:19 AM, Kevin Wolf wrote:
Commit 89bd030533e changed the test case from using job_sleep_ns() to
using qemu_co_sleep_ns() instead. Also, block_job_sleep_ns() became
job_sleep_ns() in commit 5d43e86e11f.
In both cases, some comments in the test case were not updated. Do that
now.
The setting of the DRAM address of the DMA transaction depends on the
DRAM base address and the maximum DRAM size of the SoC. Let's add a
couple of properties to give this information to the SMC controller
model.
Also, move the SDRAM Memory controller realization before the other
controllers
Emulate read errors in the DMA Checksum Register for high frequencies
and optimistic settings of the Read Timing Compensation Register. This
will help in tuning the SPI timing calibration algorithm.
The values below are those to expect from the first flash device of
the FMC controller of a
The SMC controllers have a register containing the byte that will be
used as dummy output. It can be modified by software.
Signed-off-by: Cédric Le Goater
Reviewed-by: Philippe Mathieu-Daudé
---
hw/ssi/aspeed_smc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
The FMC controller on the Aspeed SoCs support DMA to access the flash
modules. It can operate in a normal mode, to copy to or from the flash
module mapping window, or in a checksum calculation mode, to evaluate
the best clock settings for reads.
The model introduces a custom address space for
When doing calibration, the SPI clock rate in the CE0 Control Register
and the read delay cycles in the Read Timing Compensation Register are
set using bit[11:4] of the DMA Control Register.
Signed-off-by: Cédric Le Goater
---
hw/ssi/aspeed_smc.c | 64
0x should be returned for non implemented registers.
Also, the model should expose one control register per possible CS
even if there is no flash device attached. When testing the validity
of the register number in the read operation, replace 's->num_cs' by
'ctrl->max_slaves' which
On 21/09/2018 18:00, Dr. David Alan Gilbert wrote:
> * David Hildenbrand (da...@redhat.com) wrote:
>> Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
>> (memory-device part) from our pc machine hotplug handler.
>>
>> Signed-off-by: David Hildenbrand
>
> I see a few other
Signed-off-by: Cédric Le Goater
Reviewed-by: Philippe Mathieu-Daudé
---
hw/ssi/aspeed_smc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index b29bfd3124a9..1270842dcf0c 100644
--- a/hw/ssi/aspeed_smc.c
+++
The AST2500 evb is shipped with a W25Q256 which has a non volatile bit
to make the chip operate in 4 Byte address mode at power up. This
should be an interesting feature to model as it will exercise a bit
more the SMC controllers and MMIO execution at boot time.
Signed-off-by: Cédric Le Goater
The overhead for the OpenBMC firmware images using the a custom U-Boot
is around 2 seconds, which is fine, but with a U-Boot from mainline,
it takes an extra 50 seconds or so to reach Linux. A quick survey on
the number of reads performed on the flash memory region gives the
following figures :
In file included from /home/thuth/devel/qemu/hw/timer/aspeed_timer.c:16:
/home/thuth/devel/qemu/include/hw/misc/aspeed_scu.h:37:3: error:
redefinition of typedef 'AspeedSCUState' is a C11 feature
[-Werror,-Wtypedef-redefinition]
} AspeedSCUState;
^
The code looks better, it removes duplicated lines and it will ease
the introduction of common properties for the Aspeed machines.
Signed-off-by: Cédric Le Goater
Reviewed-by: Philippe Mathieu-Daudé
---
include/hw/arm/aspeed.h | 46 +
hw/arm/aspeed.c | 212
Hello,
This series adds a couple of cleanups and two main features to the
SMC controller of the Aspeed machines :
- a 'execute-in-place' property to boot directly from a memory region
alias of the FMC flash module using MMIO execution. This is not
activated by default because boot time
* David Hildenbrand (da...@redhat.com) wrote:
> Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
> (memory-device part) from our pc machine hotplug handler.
>
> Signed-off-by: David Hildenbrand
I see a few other places in the pc subdir that have checks for
TYPE_NVDIMM; can
> That all works out as something like:
>> +PCDIMMDeviceInfo *di = NULL;
>> +
>> value = info->value;
>>
>> if (value) {
>> switch (value->type) {
>> case MEMORY_DEVICE_INFO_KIND_DIMM:
>> di = value->u.dimm.data;
>>
* David Hildenbrand (da...@redhat.com) wrote:
> Account the memory to node 0 for now. Once (if ever) virtio-pmem
> supports NUMA, we can account it to the right node.
>
> Signed-off-by: David Hildenbrand
> ---
> numa.c | 25 +
> 1 file changed, 13 insertions(+), 12
* David Hildenbrand (da...@redhat.com) wrote:
> Print the memory device info just like for PCDIMM/NVDIMM.
>
> Signed-off-by: David Hildenbrand
> ---
> hmp.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/hmp.c b/hmp.c
> index
On Sat, Sep 15, 2018 at 01:32:07PM -0400, Dongjiu Geng wrote:
> This patch extends the qemu-kvm state sync logic with support for
> KVM_GET/SET_VCPU_EVENTS, giving access to yet missing SError exception.
> And also it can support the exception state migration.
>
> The SError exception states
Hi folks,
As Markus pointed out in this 'qemu-devel' thread[1],
backends/rng-random.c uses '/dev/random' in TYPE_RNG_RANDOM's
instance_init() method:
[...]
static void rng_random_init(Object *obj)
{
RngRandom *s = RNG_RANDOM(obj);
object_property_add_str(obj,
On 21 September 2018 at 06:39, Damien Hedde wrote:
> On 09/19/2018 11:30 PM, Peter Maydell wrote:
>> There are several possible approaches here I think:
>>
>> (1) the "clock" object holds no internal state; if a device on the
>> destination end of a clock connection cares about clock state then
On 09/20/2018 05:27 AM, Liu, Jing2 wrote:
Hi Marcle and Michael,
Re-ping if this is not in the PR list :)
Hi Jing,
It was on latest Michael's pull request:
http://patchwork.ozlabs.org/patch/967514/
http://patchwork.ozlabs.org/patch/967518/
Thanks for your patches!
Marcel
Thanks,
Jing
Pavel Dovgalyuk writes:
> This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
> the execution to the specified step.
> The commands automatically loads nearest snapshot and replay the execution
> to find the desired step.
>
> Signed-off-by: Pavel Dovgalyuk
>
> --
>
> v2:
> -
On 09/20/2018 05:49 PM, Laszlo Ersek wrote:
Hi Marcel,
Hi Laszlo,
I had to read this mail a few times...
this email should actually be an RFC patch. But RFC patches tend to turn
into real PATCHes (if the submitter is lucky, that is), and I can't
really promise sending multiple versions
On 9/21/18 9:10 AM, Markus Armbruster wrote:
Eric Blake writes:
[adding Markus, because of an interesting observation about
--image-opts vs. JSON null - search for [1] below]
There are four instances of [1], and my eyes glazed over before I
reached the first. May I have a summary of the
Pavel Dovgalyuk writes:
> This patch introduces replay_break qmp and hmp commands.
> These commands allow stopping at the specified instruction.
> It may be useful for debugging when there are some known
> events that should be investigated.
> The commands have one argument - number of
Now that amd-iommu support interrupt remapping, enable the GASup in IVRS
table and GASup in extended feature register to indicate that IOMMU
support guest virtual APIC mode. GASup provides option to guest OS to
make use of 128-bit IRTE.
Note that the GAMSup is set to zero to indicate that
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
---
To be consistent with intel-iommu:
- rename the address space to use '_' instead of '-'
- update the memory region relationships
Signed-off-by: Brijesh Singh
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Signed-off-by: Brijesh Singh
Cc: Peter Xu
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
Interrupt remapping needs kernel-irqchip={off|split} on both Intel and AMD
platforms. Move the check in common place.
Signed-off-by: Brijesh Singh
Reviewed-by: Peter Xu
Cc: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
The vtd_generate_msi_message() in intel-iommu is used to construct a MSI
Message from IRQ. A similar function will be needed when we add interrupt
remapping support in amd-iommu. Moving the function in common file to
avoid the code duplication. Rename it to x86_iommu_irq_to_msi_message().
There is
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e address translation
disabled and interrupt remapping enabled)
Remove the V=1 check from amdvi_validate_dte(), make
Pavel Dovgalyuk writes:
> This patch introduces 'info replay' monitor command and
> corresponding qmp request.
> These commands request the current record/replay mode, replay log file name,
> and the execution step (number or recorded/replayed instructions).
Excuse my ignorant question, please:
Pavel Dovgalyuk writes:
> Saving icount as a parameters of the snapshot allows navigation between
> them in the execution replay scenario.
> This information can be used for finding a specific snapshot for rewinding
> the recorded execution to the specific moment of the time.
> E.g., 'reverse
Eric Blake writes:
> [adding Markus, because of an interesting observation about
> --image-opts vs. JSON null - search for [1] below]
There are four instances of [1], and my eyes glazed over before I
reached the first. May I have a summary of the interesting observation?
>>>
>>> There is no such clash in VirtioPMemDeviceInfo. You could name the
>>> member "addr" there. But that would trade the inconsistency with
>>> PCDIMMDeviceInfo for an inconsistency with the device property.
>>>
>>> Is this correct?
>>>
>>
>> Yes, I chose to name it like the property. (that
On 09/19/2018 11:30 PM, Peter Maydell wrote:
> On 17 September 2018 at 01:40, wrote:
>> Regarding the migration strategy, clocks do not hold the clock state
>> internally, so there is nothing to migrate there. The consequence is that
>> a device must update its output clocks in its post_load
On 9/21/18 3:35 PM, Alberto Garcia wrote:
On Tue 18 Sep 2018 05:29:22 PM CEST, Leonid Bloch wrote:
/* New interval for cache cleanup timer */
r->cache_clean_interval =
qemu_opt_get_number(opts, QCOW2_OPT_CACHE_CLEAN_INTERVAL,
-
On 9/21/18 3:17 PM, Alberto Garcia wrote:
On Tue 18 Sep 2018 05:29:16 PM CEST, Leonid Bloch wrote:
Adding a lookup table for the powers of two, with the appropriate size
prefixes. This is needed when a size has to be stringified, in which
case something like '(1 * KiB)' would become a literal
David Hildenbrand writes:
> On 21/09/2018 14:28, Markus Armbruster wrote:
>> David Hildenbrand writes:
>>
>>> On 21/09/2018 10:07, Markus Armbruster wrote:
Quick review of just the QAPI part.
David Hildenbrand writes:
> From: Pankaj Gupta
>
> This is the
On 09/19/2018 11:30 PM, Peter Maydell wrote:
> On 17 September 2018 at 01:40, wrote:
>> Regarding the migration strategy, clocks do not hold the clock state
>> internally, so there is nothing to migrate there. The consequence is that
>> a device must update its output clocks in its post_load
Eduardo Habkost writes:
> On Fri, Sep 21, 2018 at 08:36:22AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>>
>> > On Thu, Sep 20, 2018 at 11:19:56AM -0400, Cleber Rosa wrote:
>> >> The acceptance (aka functional, aka Avocado-based) tests are
>> >> Python files located in
[Reviving this thread; and Ccing Nikos Mavrogiannopoulos of GnuTLS, a
retaining the full context.]
A clarification inline about the source of entropy for GnuTLS vs.
libgcrypt.
On Thu, Jun 28, 2018 at 01:22:24PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 28, 2018 at 02:15:14PM +0200, Markus
On Fri 21 Sep 2018 02:56:06 PM CEST, Kevin Wolf wrote:
> Am 21.09.2018 um 14:35 hat Alberto Garcia geschrieben:
>> On Tue 18 Sep 2018 05:29:22 PM CEST, Leonid Bloch wrote:
>> > /* New interval for cache cleanup timer */
>> > r->cache_clean_interval =
>> >
On Fri 14 Sep 2018 04:19:01 AM CEST, lampahome wrote:
> I figure out one way is to *divide data of device into 1TB chunk* and
> save every chunk into qcow2 image cuz I don't change filesystem, and
> connect with backing chain.
Let's see if I understood what you want:
1) you have for example a
Am 21.09.2018 um 14:35 hat Alberto Garcia geschrieben:
> On Tue 18 Sep 2018 05:29:22 PM CEST, Leonid Bloch wrote:
> > /* New interval for cache cleanup timer */
> > r->cache_clean_interval =
> > qemu_opt_get_number(opts, QCOW2_OPT_CACHE_CLEAN_INTERVAL,
> > -
Public bug reported:
Generated a u-boot image with qemu_arm_defconfig,did some modification to
qemu-arm.h.
Before added "CONFIG_SYS_FLASH_USE_BUFFER_WRITE",call saveenv in u-boot command
line can save the envirment but painful slow.
after added it,seems the action took no time,but the data
Hi Nikos,
About SPKD backtrace you got. There is something wrong with IO channel
allocation.
SPKD vhost-scsi should check the result of
spdk_scsi_dev_allocate_io_channels() in
spdk_vhost_scsi_dev_add_tgt(). But this result is not checked :(
You can add some check or assert there.
Paweł
>
>
On Tue 18 Sep 2018 05:29:22 PM CEST, Leonid Bloch wrote:
> /* New interval for cache cleanup timer */
> r->cache_clean_interval =
> qemu_opt_get_number(opts, QCOW2_OPT_CACHE_CLEAN_INTERVAL,
> -s->cache_clean_interval);
> +
On 21/09/2018 14:28, Markus Armbruster wrote:
> David Hildenbrand writes:
>
>> On 21/09/2018 10:07, Markus Armbruster wrote:
>>> Quick review of just the QAPI part.
>>>
>>> David Hildenbrand writes:
>>>
From: Pankaj Gupta
This is the current protoype of virtio-pmem. Support will
* Daniel Henrique Barboza (danielhb...@gmail.com) wrote:
> changes in v2:
> - removed the "RFC" marker;
> - added a new patch (patch 2) that removes
> bdrv_snapshot_delete_by_id_or_name from the code;
> - made changes in patch 1 as suggested by Murilo;
> - previous patch set link:
>
David Hildenbrand writes:
> On 21/09/2018 10:07, Markus Armbruster wrote:
>> Quick review of just the QAPI part.
>>
>> David Hildenbrand writes:
>>
>>> From: Pankaj Gupta
>>>
>>> This is the current protoype of virtio-pmem. Support will require
>>> machine changes for the architectures that
Hi
On Mon, Sep 10, 2018 at 12:47 PM Marc-André Lureau
wrote:
>
> This allows to pass the last failing test from the Windows HLK TPM 2.0
> TCG PPI 1.3 tests.
>
> The interface is described in the "TCG Platform Reset Attack
> Mitigation Specification", chapter 6 "ACPI _DSM Function". According
>
1 - 100 of 205 matches
Mail list logo
