Replace x = double_saturate(y) with x = add_saturate(y, y).
There is no need for a separate more specialized helper.
Signed-off-by: Richard Henderson
---
target/arm/helper.h| 1 -
target/arm/op_helper.c | 15 ---
target/arm/translate.c | 4 ++--
3 files changed, 2
The offset is variable depending on the instruction set, whereas
we have stored values for the current pc and the next pc. Passing
in the actual value is clearer in intent.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 25 ++---
Promote this function from aarch64 to fully general use.
Use it to unify the code sequences for generating illegal
opcode exceptions.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.h | 2 --
target/arm/translate.h | 2 ++
target/arm/translate-a64.c | 7 ---
Provide a common routine for the places that require ALIGN(PC, 4)
as the base address as opposed to plain PC. The two are always
the same for A32, but the difference is meaningful for thumb mode.
Signed-off-by: Richard Henderson
---
Note: This patch is easier to read with -b, as there are
The offset is variable depending on the instruction set.
Passing in the actual value is clearer in intent.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 8
target/arm/translate.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
Add a new field to retain the address of the instruction currently
being translated. The 32-bit uses are all within subroutines used
by a32 and t32. This will become less obvious when t16 support is
merged with a32+t32, and having a clear definition will help.
Convert aarch64 as well for
The thumb bit has already been removed from s->pc, and is always even.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 71d94c053b..100f958e33 100644
Unlike the other more generic gen_exception{,_internal}_insn
interfaces, breakpoints always refer to the current instruction.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 7 +++
target/arm/translate.c | 8
2 files changed, 7 insertions(+), 8 deletions(-)
This function is used in two different contexts, and it will be
clearer if the function is given the address to which it applies.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/target/arm/translate.c
We must update s->base.pc_next when we return from the translate_insn
hook to the main translator loop. By incrementing s->base.pc_next
immediately after reading the insn word, "pc_next" contains the address
of the next instruction throughout translation.
All remaining uses of s->pc are
We currently have 3 different ways of computing the architectural
value of "PC" as seen in the ARM ARM.
The value of s->pc has been incremented past the current insn,
but that is all. Thus for a32, PC = s->pc + 4; for t32, PC = s->pc;
for t16, PC = s->pc + 2. These differing computations make
These are split out of my decodetree conversion of the
aarch32 general instructions. With one exception, these
are all related to cleaning up how we refer to "PC".
r~
Richard Henderson (11):
target/arm: Pass in pc to thumb_insn_is_16bit
target/arm: Introduce pc_curr
target/arm:
Paolo, should I add include/sysemu/runstate.h to MAINTAINERS section
"Main loop"?
On Wed, Aug 7, 2019 at 5:06 AM Philippe Mathieu-Daudé wrote:
>
> On 8/5/19 8:43 AM, Bin Meng wrote:
> > On Mon, Aug 5, 2019 at 2:14 PM Chih-Min Chao
> > wrote:
> >> On Sat, Aug 3, 2019 at 8:27 AM Bin Meng wrote:
> >>>
> >>> Some of the SoC IP block sizes are wrong. Correct them according
> >>>
On Wed, Aug 7, 2019 at 5:06 AM Philippe Mathieu-Daudé wrote:
>
> On 8/5/19 8:43 AM, Bin Meng wrote:
> > On Mon, Aug 5, 2019 at 2:14 PM Chih-Min Chao
> > wrote:
> >> On Sat, Aug 3, 2019 at 8:27 AM Bin Meng wrote:
> >>>
> >>> Some of the SoC IP block sizes are wrong. Correct them according
> >>>
On 8/7/2019 7:14 AM, Daniel Black wrote:
Liu Jingqi, Tao Xu,
Apologies to the late response on a patch on what is already a v8 patch.
The specification of latency and bandwidth is very much following the
ACPI specification.
For a qemu interface I think this should be in more human
On Tue, Aug 06, 2019 at 03:51:17PM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> The purpose of the calculation is to find a HostPage which is partially
>> dirty.
>>
>> * fixup_start_addr points to the start of the HostPage to discard
>> *
Liu Jingqi, Tao Xu,
Apologies to the late response on a patch on what is already a v8 patch.
The specification of latency and bandwidth is very much following the
ACPI specification.
For a qemu interface I think this should be in more human measurements
(time for latency and a bandwidth rate
On 8/5/19 9:31 AM, Peter Maydell wrote:
On Wed, 26 Jun 2019 at 19:43, Eddie James wrote:
The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.
Both controllers use a single HW interrupt.
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 4.1 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-4.1.0-rc4.tar.xz
On 8/6/19 10:14 AM, Markus Armbruster wrote:
> Some of the generated qapi-types-MODULE.h are included all over the
> place. Changing a QAPI type can trigger massive recompiling. Top
> scorers recompile more than 1000 out of some 6600 objects (not
> counting tests and objects that don't depend on
On 7/26/19 7:49 PM, Richard Henderson wrote:
> Unify the code sequence for generating an illegal opcode exception.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
> ---
> target/arm/translate-vfp.inc.c | 3 +--
> target/arm/translate.c | 21
On 7/26/19 7:49 PM, Richard Henderson wrote:
> Add the infrastructure that will become the new decoder.
> No instructions adjusted so far.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 45 +++-
> target/arm/Makefile.objs | 18
On Tue, Aug 6, 2019 at 8:22 AM Markus Armbruster wrote:
>
> In my "build everything" tree, changing sysemu/sysemu.h triggers a
> recompile of some 5400 out of 6600 objects (not counting tests and
> objects that don't depend on qemu/osdep.h).
>
> hw/qdev-core.h includes sysemu/sysemu.h since
On Tue, Aug 6, 2019 at 8:22 AM Markus Armbruster wrote:
>
> hw/boards.h pulls in almost 60 headers. The less we include it into
> headers, the better. As a first step, drop superfluous inclusions,
> and downgrade some more to what's actually needed. Gets rid of just
> one inclusion into a
On 8/6/19 11:14 AM, Markus Armbruster wrote:
> According to hw/ide/internal's file comment, only files in hw/ide/ are
> supposed to include it. Drag reality slightly closer to supposition.
>
The downside of having your internal include ripped away and stuck in
the includes/ folder.
> Three
On Tue, Aug 6, 2019 at 8:29 AM Markus Armbruster wrote:
>
> In my "build everything" tree, changing sysemu/sysemu.h triggers a
> recompile of some 5400 out of 6600 objects (not counting tests and
> objects that don't depend on qemu/osdep.h).
>
> 119 of 380 #include directives are actually
On 02.08.19 16:03, Kevin Wolf wrote:
> The same change as commit 2b23f28639 ('block/copy-on-read: Fix
> permissions for inactive node') made for the copy-on-read driver can be
> made for bdrv_filter_default_perms(): Retaining the old permissions from
> the BdrvChild if it is given complicates
result:
node
Welcome to Node.js v12.4.0.
Type ".help" for more information.
> a = undefined
undefined
> a >>> 0
0
> let buffer
undefined
> buffer |= 0
0
Thanks for the patch :-)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 8/5/19 8:43 AM, Bin Meng wrote:
> On Mon, Aug 5, 2019 at 2:14 PM Chih-Min Chao wrote:
>> On Sat, Aug 3, 2019 at 8:27 AM Bin Meng wrote:
>>>
>>> Some of the SoC IP block sizes are wrong. Correct them according
>>> to the FE310 manual.
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>>
On 8/5/19 3:09 PM, Peter Maydell wrote:
> Factor out code to 'generate a singlestep exception', which is
> currently repeated in four places.
>
> To do this we need to also pull the identical copies of the
> gen-exception() function out of translate-a64.c and translate.c
> into translate.h.
>
>
Patchew URL:
https://patchew.org/QEMU/20190806185649.2476-1-sean.j.christopher...@intel.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Patchew URL:
https://patchew.org/QEMU/20190806185649.2476-1-sean.j.christopher...@intel.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [RFC PATCH 00/20] i386: Add support for Intel SGX
Message-id:
Because SGX EPC is enumerated through CPUID, EPC "devices" need to be
realized prior to realizing the vCPUs themselves, i.e. long before
generic devices are parsed and realized. From a virtualization
perspective, the CPUID aspect also means that EPC sections cannot be
hotplugged without
SGX EPC virtualization is currently only support by KVM.
Signed-off-by: Sean Christopherson
---
hw/i386/pc_piix.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c2280c72ef..3e70c6e311 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@
The SGX sub-leafs are enumerated at CPUID 0x12. Indices 0 and 1 are
always present when SGX is supported, and enumerate SGX features and
capabilities. Indices >=2 are directly correlated with the platform's
EPC sections. Because the number of EPC sections is dynamic and user
defined, the number
CPUID leaf 12_1_EAX is an Intel-defined feature bits leaf enumerating
the platform's SGX capabilities that may be utilized by an enclave, e.g.
whether or not an enclave can gain access to the provision key.
Currently there are six capabilities:
- INIT: set when the enclave has has been
* Singh, Brijesh (brijesh.si...@amd.com) wrote:
> Signed-off-by: Brijesh Singh
> ---
> docs/amd-memory-encryption.txt | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 43bf3ee6a5..8822cadda1
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > Now that lo_destroy() is serialized we can call unref_inode() so that
> > > all inode resources are freed.
> > >
> > >
Note that SGX EPC is currently guaranteed to reside in a single
contiguous chunk of memory regardless of the number of EPC sections.
Signed-off-by: Sean Christopherson
---
hw/i386/pc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index
The ACPI Device entry for SGX EPC is essentially a hack whose primary
purpose is to provide software with a way to autoprobe SGX support,
e.g. to allow software to implement SGX support as a driver. Details
on the individual EPC sections are not enumerated through ACPI tables,
i.e. software must
SGX EPC virtualization is currently only support by KVM.
Signed-off-by: Sean Christopherson
---
hw/i386/pc_q35.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 397e1fdd2f..ed385b8ca2 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -178,6
KVM_CAP_SGX_ATTRIBUTE is a proposed capability for Intel SGX that can be
used by userspace to enable privileged attributes, e.g. access to the
PROVISIONKEY. The capability number is a placeholder defined well above
existing capabilities so that it's stable during development.
Signed-off-by: Sean
Request SGX an SGX Launch Control to be enabled in FEATURE_CONTROL when
the features are exposed to the guest.
Signed-off-by: Sean Christopherson
---
hw/i386/pc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index
KVM (and the Linux kernel in general) restricts access to a subset of
enclave attributes to provide additional security for an uncompromised
kernel, e.g. to prevent malware from using the PROVISIONKEY to ensure
its nodes are running inside a geniune SGX enclave and/or to obtain a
stable
SGX EPC is enumerated through CPUID, i.e. EPC "devices" need to be
realized prior to realizing the vCPUs themselves, which occurs long
before generic devices are parsed and realized. Because of this,
do not allow 'sgx-epc' devices to be instantiated after vCPUS have
been created.
The 'sgx-epc'
CPUID leaf 12_1_EBX is an Intel-defined feature bits leaf enumerating
the platform's SGX extended capabilities. Currently there is a single
capabilitiy:
- EXINFO: record information about #PFs and #GPs in the enclave's SSA
Signed-off-by: Sean Christopherson
---
target/i386/cpu.c | 20
Add helpers to detect if SGX EPC exists above 4g, and if so, where SGX
EPC above 4g ends. Use the helpers to adjust the device memory range
if SGX EPC exists above 4g.
Note that SGX EPC is currently hardcoded to reside above 4g.
Signed-off-by: Sean Christopherson
---
hw/i386/pc.c
Expose SGX to the guest if and only if KVM is enabled and supports
virtualization of SGX. While the majority of ENCLS can be emulated to
some degree, because SGX uses a hardware-based root of trust, the
attestation aspects of SGX cannot be emulated in software, i.e.
ultimately emulation will fail
CPUID leaf 12_0_EAX is an Intel-defined feature bits leaf enumerating
the CPU's SGX capabilities, e.g. supported SGX instruction sets.
Currently there are four enumerated capabilities:
- SGX1 instruction set, i.e. "base" SGX
- SGX2 instruction set for dynamic EPC management
- ENCLV
This series enables exposing Intel Software Guard Extensions (SGX) to KVM
guests. This series is firmly RFC due to SGX support not yet being
accepted into the Linux kernel, let alone KVM.
The primary goal of this RFC is to get feedback on the overall approach,
especially with respect to Enclave
Add CPUID defines for SGX and SGX Launch Control (LC), as well as
defines for their associated FEATURE_CONTROL MSR bits. Define the
Launch Enclave Public Key Hash MSRs (LE Hash MSRs), which exist
when SGX LC is present (in CPUID), and are writable when SGX LC is
enabled (in FEATURE_CONTROL).
SGX adds multiple flags to FEATURE_CONTROL to enable SGX and Flexible
Launch Control.
Signed-off-by: Sean Christopherson
---
target/i386/kvm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 07565820bd..e40c4fd673 100644
---
SGX capabilities are enumerated through CPUID_0x12.
Signed-off-by: Sean Christopherson
---
target/i386/cpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a951a02baa..0e6b9980d9 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@
Save/restore the SGX Launch Enclave Public Key Hash MSRs if SGX Launch
Control (LC) is exposed to the guest. KVM advertises SGX LC via CPUID
if and only if the MSRs are writable. KVM also resets the MSRs to a
constant value (Intel's Skylake era key) when SGX LC is fully enabled,
i.e. the vCPU
EPC (Enclave Page Cache) is a specialized type of memory used by Intel
SGX (Software Guard Extensions). The SDM desribes EPC as:
The Enclave Page Cache (EPC) is the secure storage used to store
enclave pages when they are a part of an executing enclave. For an
EPC page, hardware
On Mon, Aug 5, 2019 at 5:14 AM Ivan Grokhotkov wrote:
>
> CPU-specific init functions (riscv_*_cpu_init) configure members of
> CPURISCVState, such as priv_version and resetvec. However
> riscv_cpu_realize unconditionally overwrites these members. The
> result is that some CPUs (such as
Hi Peter,
I will try the tag and report back.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1832281
Title:
tcg bug master / 4.0.0 v8 operation >>> and |=
Status in QEMU:
New
Bug description:
On 8/6/19 12:21 PM, Kevin Wolf wrote:
Am 06.08.2019 um 15:27 hat Daniel Henrique Barboza geschrieben:
diff --git a/block.c b/block.c
index c139540f2b..6e2b0f528d 100644
--- a/block.c
+++ b/block.c
@@ -621,6 +621,17 @@ int get_tmp_filename(char *filename, int size)
#endif
}
+/**
+ *
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
Reviewed-by: Dr. David Alan Gilbert
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 9d643e720c..72b841a458 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -34,7 +34,6 @@
Patchew URL: https://patchew.org/QEMU/20190806151435.10740-1-arm...@redhat.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 that
I haven't tested sh4 specifically, but arm (subject of this bug report)
definitely works, as does arm64.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Title:
Go binaries panic with "mmap
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
When memory encryption is enabled in VM, the guest RAM will be encrypted
with the guest-specific key, to protect the confidentiality of data while
in transit we need to platform specific hooks to save or migrate the
guest RAM. The MemoryEncryptionOps introduced in this patch will be later
used by
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
AMD SEV migration flow requires that target machine's public Diffie-Hellman
key (PDH) and certificate chain must be passed before initiating the guest
migration. User can use QMP 'migrate-set-parameters' to pass the certificate
chain. The certificate chain will be used while creating the outgoing
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
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
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.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Brijesh Singh
---
target/i386/sev.c | 14 ++
1 file changed, 10 insertions(+), 4
The user provides the target machine's Platform Diffie-Hellman key (PDH)
and certificate chain before starting the SEV guest migration. Cache the
certificate chain as we need them while creating the outgoing context.
Signed-off-by: Brijesh Singh
---
accel/kvm/kvm-all.c| 12 +++
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
+++
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 43bf3ee6a5..8822cadda1 100644
--- a/docs/amd-memory-encryption.txt
+++
Signed-off-by: Brijesh Singh
---
docs/amd-memory-encryption.txt | 40 +-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 8822cadda1..01d95089a8 100644
---
To enable a memory encryption inside a VM, user must pass the object
name used for the encryption in command line parameter as shown below.
# $(QEMU) \
-machine memory-encryption=
Add a helper machine_memory_encryption_enabled() which will return a bool
indicating whether the encryption object
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
Oh, that's interesting. I will verify this and if it indeed works, I
will enable Go binaries for sh4 in Debian.
Thanks a lot for the update!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Paolo Bonzini writes:
> On 02/08/19 15:16, Markus Armbruster wrote:
>> * VMChangeStateEntry and the three functions using it, obviously, along
>> with VMChangeStateHandler.
>>
>> * vm_state_notify(), because it belongs to the above.
>>
>> * The runstate_FOO() functions, because they're named
PINGING...
On 19/07/2019 19:30, Andrey Shinkevich wrote:
> In the current implementation of the QEMU bash iotests, only qemu-io
> processes may be run under the Valgrind, which is a useful tool for
> finding memory usage issues. Let's allow the common.rc bash script
> runing all the QEMU
With current QEMU (and in particular with 4.1.0 rc3 or later with commit
5bfce0b74fbd5d5308 that fixes sigaltstack) go binaries work OK. I think
we must have fixed this mmap issue at some point between when this bug
was reported and now (or possibly the go runtime was made a bit more
forgiving of
06.08.2019 19:09, Max Reitz wrote:
> On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy wrote:
>> hbitmap_reset has an unobvious property: it rounds requested region up.
>> It may provoke bugs, like in recently fixed write-blocking mode of
>> mirror: user calls reset on unaligned region, not keeping
On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy wrote:
> hbitmap_reset has an unobvious property: it rounds requested region up.
> It may provoke bugs, like in recently fixed write-blocking mode of
> mirror: user calls reset on unaligned region, not keeping in mind that
> there are possible
Patchew URL: https://patchew.org/QEMU/20190806151435.10740-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v2 00/29] Tame a few "touch this, recompile the
world" headers
On 8/6/19 8:21 AM, Peter Maydell wrote:
> On Tue, 6 Aug 2019 at 16:04, Richard Henderson
> wrote:
>>
>> On 8/6/19 3:00 AM, Peter Maydell wrote:
>>> Renaming pc_next would be a cross-target change, so let's put that
>>> on the shelf for the moment. Maybe just put a TODO comment to the
>>> effect
* Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> Hi, I'm a bit worried that this patch might have been forgotten.
> Is it queued? Thanks!
I've added it to my list for the pull I'll do as soon as 4.2 opens.
Dave
> 14.06.2019, 19:56, "Dr. David Alan Gilbert" :
> > * Yury Kotov
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> Use QEMU_IS_ALIGNED for the check, it would be more consistent with
> other align calculations.
>
> Signed-off-by: Wei Yang
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/ram.c | 7 ++-
> 1 file changed, 2 insertions(+), 5
On Tue, 6 Aug 2019 at 14:42, Peter Maydell wrote:
>
> On Tue, 6 Aug 2019 at 14:40, Gerd Hoffmann wrote:
> >
> > On Tue, Aug 06, 2019 at 01:58:19PM +0200, Cornelia Huck wrote:
> > > 'edid' is a property of the virtio-gpu base device, so turning
> > > it off on virtio-gpu-pci is not enough (it
In my "build everything" tree, changing hw/irq.h triggers a recompile
of some 5400 out of 6600 objects (not counting tests and objects that
don't depend on qemu/osdep.h).
hw/hw.h supposedly includes it for convenience. Several other headers
include it just to get qemu_irq and.or
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 5400 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
119 of 380 #include directives are actually superfluous. Delete them.
Downgrade two more to
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs, like in recently fixed write-blocking mode of
mirror: user calls reset on unaligned region, not keeping in mind that
there are possible unrelated dirty bytes, covered by rounded-up region
and information
Am 06.08.2019 um 15:27 hat Daniel Henrique Barboza geschrieben:
> > > diff --git a/block.c b/block.c
> > > index c139540f2b..6e2b0f528d 100644
> > > --- a/block.c
> > > +++ b/block.c
> > > @@ -621,6 +621,17 @@ int get_tmp_filename(char *filename, int size)
> > > #endif
> > > }
> > > +/**
> > >
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h,
On Tue, 6 Aug 2019 at 16:04, Richard Henderson
wrote:
>
> On 8/6/19 3:00 AM, Peter Maydell wrote:
> > Renaming pc_next would be a cross-target change, so let's put that
> > on the shelf for the moment. Maybe just put a TODO comment to the
> > effect that we could consider renaming in future ?
>
>
In my "build everything" tree, changing sysemu/reset.h triggers a
recompile of some 2600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
The main culprit is hw/hw.h, which supposedly includes it for
convenience.
Include sysemu/reset.h only where it's
In my "build everything" tree, changing hw/hw.h triggers a recompile
of some 2600 out of 6600 objects (not counting tests and objects that
don't depend on qemu/osdep.h).
The previous commits have left only the declaration of hw_error() in
hw/hw.h. This permits dropping most of its inclusions.
hw/boards.h pulls in almost 60 headers. The less we include it into
headers, the better. As a first step, drop superfluous inclusions,
and downgrade some more to what's actually needed. Gets rid of just
one inclusion into a header.
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Signed-off-by:
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 5400 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
hw/qdev-core.h includes sysemu/sysemu.h since recent commit e965ffa70a
"qdev: add qdev_add_vm_change_state_handler()".
Move the HostMemoryBackend typedef from sysemu/hostmem.h to
qemu/typedefs.h. This renders a few inclusions of sysemu/hostmem.h
superfluous; drop them.
Cc: Eduardo Habkost
Cc: Igor Mammedov
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eduardo Habkost
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related
to the system-emulator. Evidence:
* It's included widely: in my "build everything" tree, changing
sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600
objects (not counting tests and objects that don't
We have quite a few "touch this, recompile the world" headers. My
"build everything" tree has some 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). Touching any of 54
headers triggers a recompile of more than half of them.
This series reduces them to 46.
Six of
1 - 100 of 196 matches
Mail list logo
