Jan Bobek writes:
> On 7/3/19 6:01 PM, Peter Maydell wrote:
>> On Mon, 1 Jul 2019 at 05:43, Jan Bobek wrote:
>>>
>>> Add an x86 configuration file with all MMX instructions.
>>>
>>> Signed-off-by: Jan Bobek
>>
>>> --- /dev/null
>>> +++ b/x86.risu
>>> @@ -0,0 +1,96 @@
>>> +
> From: Peter Xu [mailto:zh...@redhat.com]
> Sent: Thursday, July 11, 2019 9:04 AM
> To: Liu, Yi L
> Subject: Re: [RFC v1 04/18] intel_iommu: add "sm_model" option
>
> On Wed, Jul 10, 2019 at 12:14:44PM +, Liu, Yi L wrote:
> > > From: Peter Xu [mailto:zh...@redhat.com]
> > > Sent: Tuesday, Ju
> From: Peter Xu [mailto:zh...@redhat.com]
> Sent: Tuesday, July 9, 2019 12:48 PM
> To: Liu, Yi L
> Cc: qemu-devel@nongnu.org; m...@redhat.com; pbonz...@redhat.com;
> alex.william...@redhat.com; eric.au...@redhat.com;
> da...@gibson.dropbear.id.au; tianyu@intel.com; Tian, Kevin
> ; Tian, Jun J
As of today, VFIO only works along with vIOMMU supporting
caching mode. The SMMUv3 does not support this mode and
requires HW nested paging to work properly with VFIO.
So any attempt to run a VFIO device protected by such IOMMU
would prevent the assigned device from working and at the
moment the g
Log a guest error when encountering an invalid STE.
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/smmuv3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 384c02cb91..2e270a0f07 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmu
On Wed, Jul 10, 2019 at 11:08:15AM +, Liu, Yi L wrote:
> > From: Peter Xu [mailto:zh...@redhat.com]
> > Sent: Tuesday, July 9, 2019 10:12 AM
> > To: Liu, Yi L
> > Subject: Re: [RFC v1 03/18] hw/pci: introduce PCIPASIDOps to PCIDevice
> >
> > On Fri, Jul 05, 2019 at 07:01:36PM +0800, Liu Yi L
We introduce a new IOMMU Memory Region attribute,
IOMMU_ATTR_VFIO_NESTED that tells whether the virtual IOMMU
requires HW nested paging for VFIO integration.
Current Intel virtual IOMMU device supports "Caching
Mode" and does not require 2 stages at physical level to be
integrated with VFIO. Howev
An IOVA/ASID invalidation is notified to all IOMMU Memory Regions
through smmuv3_inv_notifiers_iova/smmuv3_notify_iova.
When the notification occurs it is possible that some of the
PCIe devices associated to the notified regions do not have a
valid stream table entry. In that case we output a LOG_
memory_region_iommu_replay_all is not used. Remove it.
Signed-off-by: Eric Auger
Reported-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Xu
---
include/exec/memory.h | 10 --
memory.c | 9 -
2 files changed, 19 deletions(-)
diff --git a
As of today when a guest is assigned with a host PCI device and
an SMMUv3, VFIO calls memory_region_iommu_replay() default
implementation. This translates the whole address range and
completely stalls the execution. As VFIO/SMMUv3 integration
is not supported yet (it requires SMMUv3 HW nested pagin
On Thu, Jul 11, 2019 at 1:55 PM Auger Eric wrote:
>
> Hi Zhangfei,
>
> On 7/11/19 3:53 AM, Zhangfei Gao wrote:
> > On Mon, May 27, 2019 at 7:44 PM Eric Auger wrote:
> >>
> >> Up to now vSMMUv3 has not been integrated with VFIO. VFIO
> >> integration requires to program the physical IOMMU consiste
Hi Zhangfei,
On 7/11/19 3:53 AM, Zhangfei Gao wrote:
> On Mon, May 27, 2019 at 7:44 PM Eric Auger wrote:
>>
>> Up to now vSMMUv3 has not been integrated with VFIO. VFIO
>> integration requires to program the physical IOMMU consistently
>> with the guest mappings. However, as opposed to VTD, SMMUv
Thanks for the comments Fabiano.
On 05/22/2019 11:38 PM, Fabiano Rosas wrote:
Shivaprasad G Bhat writes:
+
+ddc = NVDIMM_GET_CLASS(nvdimm);
+ddc->read_label_data(nvdimm, &args[0], numBytesToRead, offset);
+
+return H_SUCCESS;
+}
+
+
+static target_ulong h_scm_write_metadata(Power
Patchew URL:
https://patchew.org/QEMU/1562823509-13072-1-git-send-email-jing2@linux.intel.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing
On 05/14/2019 10:08 AM, David Gibson wrote:
On Mon, May 13, 2019 at 04:28:36AM -0500, Shivaprasad G Bhat wrote:
This patch implements few of the necessary hcalls for the nvdimm support.
PAPR semantics is such that each NVDIMM device is comprising of multiple
SCM(Storage Class Memory) blocks.
Intel CooperLake cpu adds AVX512_BF16 instruction, defining as
CPUID.(EAX=7,ECX=1):EAX[bit 05].
The release spec link as follows,
https://software.intel.com/sites/default/files/managed/c5/15/\
architecture-instruction-set-extensions-programming-reference.pdf
Signed-off-by: Jing Liu
---
target/i
Hi,
The qemu upstream (at commit 6df2cdf44a at the moment) fails to compile
with nettle 3.5.1. It seems that Nettle has deprecated a few parts of
its API.
A workaround is to provide --disable-nettle during qemu configuration.
A portion of the error log:
error: ‘nettle_aes_encrypt’ is deprecated
Public bug reported:
Just want to pulse about the plan to update u-boot binary to latest
v2019.07.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
On Thu, Jul 11, 2019 at 11:31:00AM +1000, David Gibson wrote:
> On Wed, Jul 10, 2019 at 11:36:21AM +0530, Bharata B Rao wrote:
> > A pseries guest can be run as a secure guest on Ultravisor-enabled
> > POWER platforms. When such a secure guest is reset, we need to
> > release/reset a few resources
Hi Kirti,
There are still unaddressed comments to your patches v4.
Would you mind addressing them?
1. should we register two migration interfaces simultaneously
(https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04750.html)
2. in each save iteration, how much data is to be saved
(https://li
Hi Philippe.
Thanks for you review.
Please explain how to link a device.
Regards,
Michael
On Wed, Jul 10, 2019 at 1:06 PM Philippe Mathieu-Daudé
wrote:
> Hi Michael, Sarah.
>
> Sorry for reviewing this series that late.
>
> On 7/9/19 11:36 PM, Michael Rolnik wrote:
> > From: Sarah Harris
> >
On Wed, Jul 10, 2019 at 11:36:21AM +0530, Bharata B Rao wrote:
> A pseries guest can be run as a secure guest on Ultravisor-enabled
> POWER platforms. When such a secure guest is reset, we need to
> release/reset a few resources both on ultravisor and hypervisor side.
> This is achieved by invoking
On Wed, Jul 10, 2019 at 06:26:09PM +0200, Laurent Vivier wrote:
> On 29/05/2019 08:50, David Gibson wrote:
> > From: Cédric Le Goater
> >
> > Now that XIVE support is complete (QEMU emulated and KVM devices),
> > change the pseries machine to advertise both interrupt modes: XICS
> > (P7/P8) and X
On Tue, Jul 09, 2019 at 11:12:13PM -0700, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190710060621.16430-1-bhar...@linux.ibm.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Message-id: 20190710
On Thu, Jul 11, 2019 at 4:23 AM Cleber Rosa wrote:
> On Wed, Jul 10, 2019 at 10:50:23AM -0700, Chih-Min Chao wrote:
> > Similar to the mips + malta test, it boots a Linux kernel on a virt
> > board and verify the serial is working. Also, it relies on the serial
> > device set by the machine itse
On Thu, Jul 11, 2019 at 2:53 AM Alistair Francis
wrote:
> On Wed, Jul 10, 2019 at 10:51 AM Chih-Min Chao
> wrote:
> >
> > Similar to the mips + malta test, it boots a Linux kernel on a virt
> > board and verify the serial is working. Also, it relies on the serial
> > device set by the machine i
On Mon, May 27, 2019 at 7:44 PM Eric Auger wrote:
>
> Up to now vSMMUv3 has not been integrated with VFIO. VFIO
> integration requires to program the physical IOMMU consistently
> with the guest mappings. However, as opposed to VTD, SMMUv3 has
> no "Caching Mode" which allows easy trapping of gues
On 7/9/19 7:25 PM, John Snow wrote:
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 416 +++
> tests/qemu-iotests/257.out | 2247
> tests/qemu-iotests/group |1 +
> 3 files changed, 2664 insertions(+)
> create mode 100755 tests/q
On Wed, Jul 10, 2019 at 11:51:17AM +, Liu, Yi L wrote:
[...]
> > > +s->vcrsp = 1;
> > > +vtd_set_quad_raw(s, DMAR_VCRSP_REG,
> > > + ((uint64_t) s->vcrsp));
> >
> > Do we really need to emulate the "In Progress" like this? The vcpu is
> > blocked here
On Wed, Jul 10, 2019 at 03:01:53PM -0700, Guenter Roeck wrote:
> Hi,
>
> when trying to run "make -j30 install" from a clean tree on v4.1.0-rc0, I get
> _lots_ of undefined symbol errors.
>
> If I run "make -j30" followed by "make -j30 install", make succeeds, but then
> I get linker errors such
On Wed, Jul 10, 2019 at 05:14:07PM -0700, Alistair Francis wrote:
> If the user hasn't specified a firmware to load (with -bios) or
> specified no bios (with -bios none) then load OpenSBI by default. This
> allows users to boot a RISC-V kernel with just -kernel.
>
> Signed-off-by: Alistair Francis
On Wed, Jul 10, 2019 at 05:14:04PM -0700, Alistair Francis wrote:
> Add OpenSBI version 0.4 as a git submodule and as a prebult binary.
>
> OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
> reference implementation of the RISC-V Supervisor Binary Interface (SBI)
> specifi
On Wed, Jul 10, 2019 at 12:14:44PM +, Liu, Yi L wrote:
> > From: Peter Xu [mailto:zh...@redhat.com]
> > Sent: Tuesday, July 9, 2019 10:16 AM
> > To: Liu, Yi L
> > Subject: Re: [RFC v1 04/18] intel_iommu: add "sm_model" option
> >
> > On Fri, Jul 05, 2019 at 07:01:37PM +0800, Liu Yi L wrote:
>
On Wed, Jul 10, 2019 at 05:14:04PM -0700, Alistair Francis wrote:
> Add OpenSBI version 0.4 as a git submodule and as a prebult binary.
>
> OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
> reference implementation of the RISC-V Supervisor Binary Interface (SBI)
> specifi
On Wed, 2019-07-10 at 23:09 +0200, Kevin Wolf wrote:
> Am 10.07.2019 um 13:33 hat Paolo Bonzini geschrieben:
> > On 10/07/19 13:02, Kevin Wolf wrote:
> > > Hm... Actually, file-posix implements .bdrv_check_perm and could just
> > > refuse attaching a parent there if it doesn't request a specific
>
Add OpenSBI version 0.4 as a git submodule and as a prebult binary.
OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
reference implementation of the RISC-V Supervisor Binary Interface (SBI)
specifications for platform-specific firmwares executing in M-mode. For all
support
If the user hasn't specified a firmware to load (with -bios) or
specified no bios (with -bios none) then load OpenSBI by default. This
allows users to boot a RISC-V kernel with just -kernel.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
hw/riscv/boot.c |
This series includes the OpenSBI firmware for QEMU RISC-V users.
To avoid breakages we have not changed the default behaviour of QEMU.
The plan is to change the default though, which is why an entry to the
qemu-deprecated.texi file has been added as well as a new warning.
After this series QEMU 4
On Mon, Jul 8, 2019 at 9:32 AM Fabien Chouteau wrote:
>
> Hi Bin,
>
> Thanks for this patch.
>
> I know I am very late to the game but I have a comment here.
>
> On 17/05/2019 17:51, Bin Meng wrote:
> > +/* create PLIC hart topology configuration string */
> > +plic_hart_config_len = (strl
On Wed, Jul 10, 2019 at 3:46 PM Guenter Roeck wrote:
>
> On Mon, Jul 08, 2019 at 11:49:40AM -0700, Alistair Francis wrote:
> > If the user hasn't specified a firmware to load (with -bios) or
> > specified no bios (with -bios none) then load OpenSBI by default. This
> > allows users to boot a RISC-
If SDL2 is requested but pkg-config doesn't have a module for it
configure should fallback to use sdl*-config, but wasn't able to
because and old variable (from SDL) was being used by mistake.
Correct the variable name and complete other related changes so
there are no more references to the old S
On Mon, Jul 08, 2019 at 11:49:40AM -0700, Alistair Francis wrote:
> If the user hasn't specified a firmware to load (with -bios) or
> specified no bios (with -bios none) then load OpenSBI by default. This
> allows users to boot a RISC-V kernel with just -kernel.
>
> Signed-off-by: Alistair Francis
Hi,
when trying to run "make -j30 install" from a clean tree on v4.1.0-rc0, I get
_lots_ of undefined symbol errors.
If I run "make -j30" followed by "make -j30 install", make succeeds, but then
I get linker errors such as the following when running "make -j30 install".
/usr/bin/ld: final link f
On 10.07.19 23:24, Max Reitz wrote:
> On 10.07.19 19:03, Maxim Levitsky wrote:
>> preallocation=off and preallocation=metadata
>> both allocate luks header only, and preallocation=falloc/full
>> is passed to underlying file, with the given image size.
>>
>> Note that the actual preallocated size is
Ping
I suppose I’ll apply the patches I had in v1 if I don’t get reviews for
the new patches, because some fixes are better than none.
(And probably patch 2, because it’s obvious.)
Max
On 03.07.19 19:28, Max Reitz wrote:
> This is a v2 to “block: Add BDS.never_freeze”.
>
> It depends on my “bl
On 10.07.19 19:03, Maxim Levitsky wrote:
> preallocation=off and preallocation=metadata
> both allocate luks header only, and preallocation=falloc/full
> is passed to underlying file, with the given image size.
>
> Note that the actual preallocated size is a bit smaller due
> to luks header.
Coul
Am 10.07.2019 um 13:33 hat Paolo Bonzini geschrieben:
> On 10/07/19 13:02, Kevin Wolf wrote:
> > Hm... Actually, file-posix implements .bdrv_check_perm and could just
> > refuse attaching a parent there if it doesn't request a specific
> > permission like BLK_PERM_SUPPORT_ZONED. That should give us
On 10.07.19 16:57, Michal Privoznik wrote:
> When creating the admin queue in nvme_init() the variable that
> holds the number of queues created is modified before actual
> queue creation. This is a problem because if creating the queue
> fails then the variable is left in inconsistent state. This
Patchew URL:
https://patchew.org/QEMU/20190710202219.25939-1-brijesh.si...@amd.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit th
On 10.07.19 22:47, John Snow wrote:
>
>
> On 7/10/19 4:30 PM, Max Reitz wrote:
>> On 10.07.19 20:20, John Snow wrote:
>>>
>>>
>>> On 7/10/19 12:36 PM, Max Reitz wrote:
On 10.07.19 03:05, John Snow wrote:
> The way bitmap backups work is by starting at 75% if it needs
> to copy just 2
Patchew URL:
https://patchew.org/QEMU/20190710202219.25939-1-brijesh.si...@amd.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v2 00/13] Add SEV guest live migration support
Type: series
Message-id: 20190710202
On 7/10/19 4:30 PM, Max Reitz wrote:
> On 10.07.19 20:20, John Snow wrote:
>>
>>
>> On 7/10/19 12:36 PM, Max Reitz wrote:
>>> On 10.07.19 03:05, John Snow wrote:
The way bitmap backups work is by starting at 75% if it needs
to copy just 25% of the disk.
>>>
>>> Although there is this c
On 10.07.19 21:00, John Snow wrote:
>
>
> On 7/10/19 1:14 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> Signed-off-by: John Snow
>>> ---
>>> tests/qemu-iotests/257 | 31 +
>>> tests/qemu-iotests/257.out | 3089
>>> 2 files changed, 31
On 10.07.19 20:32, John Snow wrote:
>
>
> On 7/10/19 12:48 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> Accept bitmaps and sync policies for the other backup modes.
>>> This allows us to do things like create a bitmap synced to a full backup
>>> without a transaction, or start
On Wed, Jul 10, 2019 at 10:50:23AM -0700, Chih-Min Chao wrote:
> Similar to the mips + malta test, it boots a Linux kernel on a virt
> board and verify the serial is working. Also, it relies on the serial
> device set by the machine itself.
>
> If riscv64 is a target being built, "make check-acce
When memory encryption is enabled, the hypervisor maintains a page
encryption bitmap which is referred by hypervisor during migratoin to check
if page is private or shared. The bitmap is built during the VM bootup and
must be migrated to the target host so that hypervisor on target host can
use it
Encrypted VMs have concept of private and shared memory. The private
memory is encrypted with the guest-specific key, while shared memory
may be encrypted with hyperivosr key. The guest OS uses a hypercall
to notify the page encryption state to the hypervisor. The hypervisor
maintain a bitmap of pa
The sev_load_incoming_page() provide the implementation to read the
incoming guest private pages from the socket and load it into the guest
memory. The routines uses the RECEIVE_START command to create the
incoming encryption context on the first call then uses the
RECEIEVE_UPDATE_DATA command to l
On 10.07.19 20:20, John Snow wrote:
>
>
> On 7/10/19 12:36 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> The way bitmap backups work is by starting at 75% if it needs
>>> to copy just 25% of the disk.
>>
>> Although there is this comment:
>>
>>> /* TODO job_progress_set_remainin
The command can be used by the hypervisor to specify the target Platform
Diffie-Hellman key (PDH) and certificate chain before starting the SEV
guest migration. The values passed through the command will be used while
creating the outgoing encryption context.
Signed-off-by: Brijesh Singh
---
qap
The SEV VMs have concept of private and shared memory. The private memory
is encrypted with guest-specific key, while shared memory may be encrypted
with hyperivosr key. The KVM_GET_PAGE_ENC_BITMAP can be used to get a
bitmap indicating whether the guest page is private or shared. A private
page mu
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 43bf3ee6a5..abb9a976f5 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryp
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index abb9a976f5..374f4b0a94 100644
--- a/docs/amd-memory-encrypti
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 12
1 file changed, 12 deletions(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 93c6a90806..48336515a2 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -34,7 +34,6 @@
#define DEFAULT_SEV_DEVICE "/dev/se
The sev_save_outgoing_page() provide the implementation to encrypt the
guest private pages during the transit. The routines uses the SEND_START
command to create the outgoing encryption context on the first call then
uses the SEND_UPDATE_DATA command to encrypt the data before writing it
to the soc
Signed-off-by: Brijesh Singh
---
linux-headers/linux/kvm.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c8423e760c..2b0a2a97b8 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/lin
The LAUNCH_START is used for creating an encryption context to encrypt
newly created guest, for an incoming guest the RECEIVE_START should be
used.
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/target/i386/s
When memory encryption is enabled, the guest memory will be encrypted with
the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
flag to distinguish the encrypted data from plaintext. Encrypted pages
may need special handling. The kvm_memcrypt_save_outgoing_page() is used
by the
When memory encryption is enabled in VM, the guest pages will be
encrypted with the guest-specific key, to protect the confidentiality
of data in transit. To support the live migration we need to use
platform specific hooks to access the guest memory.
The kvm_memcrypt_save_outgoing_page() can be u
AMD SEV encrypts the memory of VMs and because this encryption is done using
an address tweak, the hypervisor will not be able to simply copy ciphertext
between machines to migrate a VM. Instead the AMD SEV Key Management API
provides a set of functions which the hypervisor can use to package a
gue
On 10.07.19 19:57, John Snow wrote:
>
>
> On 7/10/19 12:11 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> This is nicer to do in the unified QMP interface that we have now,
>>> because it lets us use the right terminology back at the user.
>>>
>>> Signed-off-by: John Snow
>>> --
On 10.07.19 19:52, John Snow wrote:
>
>
> On 7/10/19 12:04 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> This test needs support for non-bitmap backups and missing or
>>> unspecified bitmap sync modes, so rewrite the helpers to be a little
>>> more generic.
>>>
>>> Signed-off-by
On Mon, 8 Jul 2019 at 10:43, Yuval Shaia wrote:
>
> On Sat, Jul 06, 2019 at 09:39:40AM +0530, Sukrit Bhatnagar wrote:
> > Use VMStateDescription for migrating device state. Currently,
>
> What do you mean by 'Currently'?
I meant that 'vmstate_pvrdma' will contain more fields later. This is
how it
On Tue, Jul 9, 2019 at 10:53 PM Kővágó, Zoltán wrote:
>
> Unless we disable stream moving, pulseaudio can easily move the stream
> on connect, effectively ignoring the source/sink specified by the user.
>
> Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
> ---
> audio/paaudio.c
On Tue, Jul 9, 2019 at 10:58 PM Kővágó, Zoltán wrote:
>
> Finally add audiodev= options to audio frontends so users can specify
> which backend to use when multiple backends exist. Not specifying an
> audiodev= option currently causes the first audiodev to be used, this is
> fixed in the next com
On Tue, Jul 9, 2019 at 11:02 PM Kővágó, Zoltán wrote:
>
> Audio functions no longer access glob_audio_state, instead they get an
> AudioState as a parameter. This is required in order to support
> multiple backends.
>
> glob_audio_state is also gone, and replaced with a tailq so we can store
> mo
On Tue, Jul 9, 2019 at 11:08 PM Kővágó, Zoltán wrote:
>
> There's already a MIN and MAX macro in include/qemu/osdep.h, use them
> instead.
>
> Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
> ---
> audio/audio.h | 17 -
> audio/alsaaudio.c |
On Tue, Jul 9, 2019 at 10:57 PM Kővágó, Zoltán wrote:
>
> Remove glob_audio_state from functions, where possible without breaking
> the API. This means that most static functions in audio.c now take an
> AudioState pointer instead of implicitly using glob_audio_state. Also
> included a pointer i
On Tue, Jul 9, 2019 at 10:53 PM Kővágó, Zoltán wrote:
>
> Currently this needs a workaround due to bug #247 in pulseaudio.
>
> Signed-off-by: Kővágó, Zoltán
> ---
> audio/paaudio.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/audio/paaudio.c
On Tue, Jul 9, 2019 at 10:51 PM Kővágó, Zoltán wrote:
>
> audio_run is called manually by alsa and oss backends when polling.
> In this case only the requesting backend should be run, not all of them.
>
> Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
> ---
> audio/audio_int.h
On Tue, Jul 9, 2019 at 10:49 PM Kővágó, Zoltán wrote:
>
> Pulseaudio normally assumes that when the server wants it, the client
> can generate the audio samples and send it right away. Unfortunately
> this is not the case with QEMU -- it's up to the emulated system when
> does it generate the sam
On Tue, Jul 9, 2019 at 10:57 PM Kővágó, Zoltán wrote:
>
> They just called audio_pcm_sw_read/write anyway, so it makes no sense
> to have them too. (The noaudio's read is the only exception, but it
> should work with the generic code too.)
It works with the generic code, but wouldn't it be more
On 2019-07-10 06:06, Markus Armbruster wrote:
> "Kővágó, Zoltán" writes:
>
>> Audio functions no longer access glob_audio_state, instead they get an
>> AudioState as a parameter. This is required in order to support
>> multiple backends.
>>
>> glob_audio_state is also gone, and replaced with a t
On Tue, Jul 9, 2019 at 11:00 PM Kővágó, Zoltán wrote:
>
> This means you should probably stop using -soundhw (as it doesn't allow
> you to specify any options) and add the device manually with -device.
> The exception is pcspk, it's currently not possible to manually add it.
> To use it with audio
The annotated style json we use in QMP documentation is not strict json
and depending on the version of Sphinx (2.0+) or Pygments installed,
might cause the build to fail.
Use the new QMP lexer.
Further, some versions of Sphinx can not apply custom lexers to "code"
directives and require the use
The following changes since commit 6df2cdf44a82426f7a59dcb03f0dd2181ed7fdfa:
Update version for v4.1.0-rc0 release (2019-07-09 17:21:53 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/bitmaps-pull-request
for you to fetch changes up to a7786bfb0effe0b4
Sphinx, through Pygments, does not like annotated json examples very
much. In some versions of Sphinx (1.7), it will render the non-json
portions of code blocks in red, but in newer versions (2.0) it will
throw an exception and not highlight the block at all. Though we can
suppress this warning, it
Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches
these errors.
Signed-off-by: John Snow
Reported-by: Aarushi Mehta
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190603214653.29369-2-js...@redhat.com
Signed-off-by: John Snow
---
docs/interop/bitmaps.rst | 4 ++--
On 7/10/19 1:14 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/257 | 31 +
>> tests/qemu-iotests/257.out | 3089
>> 2 files changed, 3120 insertions(+)
>
> Oof.
>
Yeah, it's... a
On Wed, Jul 10, 2019 at 10:51 AM Chih-Min Chao wrote:
>
> Similar to the mips + malta test, it boots a Linux kernel on a virt
> board and verify the serial is working. Also, it relies on the serial
> device set by the machine itself.
>
> If riscv64 is a target being built, "make check-acceptance"
On 7/3/19 6:01 PM, Peter Maydell wrote:
> On Mon, 1 Jul 2019 at 05:43, Jan Bobek wrote:
>>
>> Add an x86 configuration file with all MMX instructions.
>>
>> Signed-off-by: Jan Bobek
>
>> --- /dev/null
>> +++ b/x86.risu
>> @@ -0,0 +1,96 @@
>> +#
On 7/10/19 12:48 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Accept bitmaps and sync policies for the other backup modes.
>> This allows us to do things like create a bitmap synced to a full backup
>> without a transaction, or start a resumable backup process.
>>
>> Some combin
On 7/3/19 5:49 PM, Richard Henderson wrote:
> On 7/1/19 6:35 AM, Jan Bobek wrote:
>> +MOVQMMX 011 d 1110 !emit { rex(w => 1); modrm(mod
>> => MOD_DIRECT, rm => ~REG_ESP); }
>> +MOVQ_memMMX 011 d 1110 !emit { rex(w => 1); modrm(mod
>> => ~MOD_DIRECT);
On 7/3/19 5:35 PM, Richard Henderson wrote:
> On 7/1/19 6:35 AM, Jan Bobek wrote:
>> Add an x86 configuration file with all MMX instructions.
>>
>> Signed-off-by: Jan Bobek
>> ---
>> x86.risu | 96
>> 1 file changed, 96 insertions(+)
>> cr
On 7/3/19 12:11 PM, Richard Henderson wrote:
> On 7/1/19 6:35 AM, Jan Bobek wrote:
>> +sub write_mov_rr($$)
>> +{
>> +my ($r1, $r2) = @_;
>> +
>> +my %insn = (opcode => X86OP_MOV,
>> +modrm => {mod => MOD_DIRECT,
>> + reg => ($r1 & 0x7),
>> +
On 7/10/19 12:36 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> The way bitmap backups work is by starting at 75% if it needs
>> to copy just 25% of the disk.
>
> Although there is this comment:
>
>> /* TODO job_progress_set_remaining() would make more sense */
>
> So...
>
>>
Lucien Murray-Pitts writes:
>> On Wed, Jul 10, 2019 at 4:04 AM Richard Henderson <
> richard.hender...@linaro.org> wrote:
>
>> > I did have a suggestion. It was fairly detailed.
>> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>>
>> Your solution is elegant at about 10
On Tue, Jul 9, 2019 at 8:56 PM Richard Henderson
wrote:
>
> The aarch64 argument ordering for the operands is big-endian,
> whereas the tcg argument ordering is little-endian. Use REG0
> so that we honor the rZ constraints.
Hello, Richard.
If endian and rZ constraints are unrelated problems, th
On 7/3/19 11:47 AM, Richard Henderson wrote:
> On 7/1/19 6:35 AM, Jan Bobek wrote:
>> +sub parse_emitblock($$)
>> +{
>> +my ($rec, $insn) = @_;
>> +my $insnname = $rec->{name};
>> +my $opcode = $insn->{opcode}{value};
>> +
>> +$emit_opts = {};
>> +
>> +my $emitblock = $rec->{blo
On 7/3/19 11:37 AM, Richard Henderson wrote:
> On 7/1/19 6:35 AM, Jan Bobek wrote:
>> +VEX_V_UNUSED => 0b,
>
> I think perhaps this is a mistake. Yes, that's what goes in the field, but
> what goes in the field is ~(logical_value).
>
> While for general RISU-ish operation, ~(random_numbe
1 - 100 of 225 matches
Mail list logo
