Signed-off-by: Bastian Koppelmann
---
tests/tcg/tricore/Makefile.softmmu-target | 1 +
tests/tcg/tricore/macros.h| 18 ++
tests/tcg/tricore/test_madd.S | 11 +++
3 files changed, 30 insertions(+)
create mode 100644
This kind of tests is inspired by the riscv-tests repository. This adds
macros that makes it easy to create single instruction self containing
tests.
It is achieved by macros that create a test sequence for an
instruction and check for a supplied correct value. If the value is correct the
next
Signed-off-by: Bastian Koppelmann
---
tests/tcg/tricore/Makefile.softmmu-target | 1 +
tests/tcg/tricore/macros.h| 7 +++
tests/tcg/tricore/test_ftoi.S | 10 ++
3 files changed, 18 insertions(+)
create mode 100644 tests/tcg/tricore/test_ftoi.S
diff
Signed-off-by: Bastian Koppelmann
---
tests/tcg/tricore/Makefile.softmmu-target | 1 +
tests/tcg/tricore/test_muls.S | 9 +
2 files changed, 10 insertions(+)
create mode 100644 tests/tcg/tricore/test_muls.S
diff --git a/tests/tcg/tricore/Makefile.softmmu-target
when trying to run successful short tests from the Makefile timeout would no
terminate. Rather it would wait until the time runs out. Excerpt from the
manpage:
--foreground
when not running timeout directly from a shell prompt,
allow COMMAND to read from the TTY and get TTY signals; in
At least for the TriCore target no easily available c compiler exists.
Thus we need to rely on "as" and "ld". This allows us to run them
through the docker image.
Signed-off-by: Bastian Koppelmann
---
tests/tcg/Makefile.qemu | 11 +++
tests/tcg/configure.sh | 2 ++
2 files changed, 13
Signed-off-by: Bastian Koppelmann
---
tests/tcg/tricore/Makefile.softmmu-target | 1 +
tests/tcg/tricore/macros.h| 24 +++
tests/tcg/tricore/test_bmerge.S | 8
3 files changed, 33 insertions(+)
create mode 100644
Hi Alex,
I managed to update the series to successfully run make check-tcg. This required
some changes to the makefiles. I tried running the riscv64 and arm tests and so
far I didn't break anything.
You can find the full tree here:
https://github.com/bkoppelmann/qemu/tree/tricore-tcg-tests
we get an authentication errror when trying to pull qemu:debian9. Thus
just start from a plain debian image.
Signed-off-by: Bastian Koppelmann
---
.../dockerfiles/debian-tricore-cross.docker | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
this device is used to verify the correctness of regression tests by
allowing guests to write their exit status to this device. This is then
used by qemu to exit using the written status.
Signed-off-by: Bastian Koppelmann
---
hw/tricore/Makefile.objs| 2 +-
this includes the Makefile and linker script to build all the tests.
Signed-off-by: Bastian Koppelmann
---
tests/tcg/tricore/Makefile.softmmu-target | 17 +++
tests/tcg/tricore/link.ld | 60 +++
2 files changed, 77 insertions(+)
create mode 100644
Hi,
while debugging a report I got in Ubuntu I found that since qemu 4.0 the
guest agent shutdown feature works (guest is shutting down) but crashes
when doing so each time. This can be a big red herring when debugging other
things as well as people start to get "an application crashed, do you
Hi Richard,
Recently we are doing some tests on forward migration based on
arm virt machine. And we found the patch below breaks forward
migration compatibility from virt-4.2 to virt-5.0 above machine
type. The patch which breaks this down given by git bisect is
commit
On Thu, Jun 04, 2020 at 09:59:41AM +0200, Gerd Hoffmann wrote:
>
There's no info here, or in the commit message about the
intended goal of this modularization ? If we're modularizing
devices, why only qxl and not other devices too ?
>
> Gerd Hoffmann (2):
> qdev: add support for device module
On Thu, Jun 04, 2020 at 12:25:22AM +0530, P J P wrote:
> From: Prasad J Pandit
>
> While accessing VGA registers via ati_mm_read/write routines,
> a guest may set 's->regs.mm_index' such that it leads to infinite
> recursion. Check mm_index value to avoid it.
So this is a denial of service
Typo: s/ait/ati/
On Thu, Jun 04, 2020 at 01:52:50AM +0530, P J P wrote:
> From: Prasad J Pandit
>
> While reading PCI configuration bytes, a guest may send an
> address towards the end of the configuration space. It may lead
> to an OOB access issue. Add check to ensure 'address + size' is
>
Hello David,
David Gibson writes:
> A number of hardware platforms are implementing mechanisms whereby the
> hypervisor does not have unfettered access to guest memory, in order
> to mitigate the security impact of a compromised hypervisor.
>
> AMD's SEV implements this with in-cpu memory
It is possible, that shutdown on target occurs earlier than migration
finish. In this case we crash in bdrv_release_dirty_bitmap_locked()
on assertion "assert(!bdrv_dirty_bitmap_busy(bitmap));" as we do have
busy bitmap, as bitmap migration is ongoing.
We'll fix bitmap migration to gracefully
Patchew URL: https://patchew.org/QEMU/20200604075943.7001-1-kra...@redhat.com/
Hi,
This series failed the docker-mingw@fedora 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/20200604075943.7001-1-kra...@redhat.com/
Hi,
This series failed the docker-quick@centos7 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 ===
On 1/29/20 10:23 PM, Philippe Mathieu-Daudé wrote:
[...]
> accel/accel: Make TYPE_ACCEL abstract
> python/qemu: Add binutils::binary_get_version()
> tests/acceptance: Use 'version-min' tag to verify QEMU binary version
> tests/acceptance: Restrict X86CPUModelAliases test to QEMU >= 4.1
>
On Wed, 2020-06-03 at 09:11 -0500, Eric Blake wrote:
> On 6/3/20 6:47 AM, Robert Hoo wrote:
> > Complement versioned CPU model framework with the ability of
> > marking some
> > versions deprecated. When that CPU model is chosen, get some
> > warning. The
> > warning message is customized, e.g.
Open questions:
* Do we want this be contigurable? If so, how? Does our miniconf
support tristate Kconfig options?
* The Makefile.target chunk feels quite hackish. Better ideas anyone?
Signed-off-by: Gerd Hoffmann
---
Makefile.objs| 1 +
Makefile.target | 7 +++
Gerd Hoffmann (2):
qdev: add support for device module loading
vga: build qxl as module
Makefile.objs| 1 +
Makefile.target | 7 ++
include/hw/qdev-core.h | 3 +++
include/qemu/module.h| 1 +
hw/core/qdev.c | 49
When compiling devices as modules we'll need some infrastrtucture to
actually load those modules. This patch adds it.
FIXME: Probably need to sprinkle a qdev_module_load_all() call somewhere
into monitor code to make QOM introspection work properly for modular
devices. Didn't manage yet to find
Thank you very much dear colleagues for your collaboration. Your reviews
comments are well noted.
Andrey
From: Eric Blake
Sent: Tuesday, June 2, 2020 12:46 AM
To: Andrey Shinkevich ; qemu-bl...@nongnu.org
Cc: qemu-devel@nongnu.org ; kw...@redhat.com
;
04.06.2020 10:21, Thomas Huth wrote:
On 03/06/2020 10.06, Vladimir Sementsov-Ogievskiy wrote:
03.06.2020 10:52, Thomas Huth wrote:
On 22/05/2020 00.06, Vladimir Sementsov-Ogievskiy wrote:
Test that dirty bitmap migration works when we deal with mirror.
Signed-off-by: Vladimir
Hello Dave,
==[background]==
I've been doing this pflash rework:
* Add abstract TYPE_NOR_FLASH
- qdev type
- blockdev backend
- manage bank/sector,
- manage timer for erase/write delays
- can be used by I2C/SPI NOR flash too
* Add abstract TYPE_PARALLEL_NOR_FLASH
- mostly
Still exists in QEMU emulator version 5.0.0 (Debian 1:5.0-5) running
on Linux 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64
GNU/Linux
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 03/06/2020 10.06, Vladimir Sementsov-Ogievskiy wrote:
> 03.06.2020 10:52, Thomas Huth wrote:
>> On 22/05/2020 00.06, Vladimir Sementsov-Ogievskiy wrote:
>>> Test that dirty bitmap migration works when we deal with mirror.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>>> Reviewed-by:
On 6/3/2020 4:26 PM, Andrew Jones wrote:
On Wed, Jun 03, 2020 at 10:02:08AM +0800, Ying Fang wrote:
Virtual time adjustment was implemented for virt-5.0 machine type,
but the cpu property was enabled only for host-passthrough and
max cpu model. Let's add it for arm cpu which has the gernic
On 6/4/20 8:42 AM, David Gibson wrote:
> The SEV code uses a pretty ugly global to access its internal state. Now
> that SEVState is embedded in SevGuestState, we can avoid accessing it via
> the global in some cases. In the remaining cases use a new global
> referencing the containing
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> Drop and replace rip field from HVFX86EmulatorState in favor of eip from
> common CPUX86State.
>
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/hvf.c| 6 +--
> target/i386/hvf/x86.h| 3 --
> target/i386/hvf/x86_decode.c |
SEVState is contained with SevGuestState. We've now fixed redundancies
and name conflicts, so there's no real point to the nested structure. Just
move all the fields of SEVState into SevGuestState.
This eliminates the SEVState structure, which as a bonus removes the
confusion with the SevState
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> The lazy flags are still needed for instruction decoder.
>
> Signed-off-by: Roman Bolshakov
> ---
> include/sysemu/hvf.h| 7 +
> target/i386/cpu.h | 2 ++
> target/i386/hvf/x86.h | 6
> target/i386/hvf/x86_flags.c
SEVState::policy is set from the final value of the policy field in the
parameter structure for the KVM_SEV_LAUNCH_START ioctl(). But, AFAICT
that ioctl() won't ever change it from the original supplied value which
comes from SevGuestState::policy.
So, remove this field and just use
The user can explicitly specify a handle via the "handle" property wired
to SevGuestState::handle. That gets passed to the KVM_SEV_LAUNCH_START
ioctl() which may update it, the final value being copied back to both
SevGuestState::handle and SEVState::handle.
AFAICT, nothing will be looking
The SEV code uses a pretty ugly global to access its internal state. Now
that SEVState is embedded in SevGuestState, we can avoid accessing it via
the global in some cases. In the remaining cases use a new global
referencing the containing SevGuestState which will simplify some future
The SEVState structure has cbitpos and reduced_phys_bits fields which are
simply copied from the SevGuestState structure and never changed. Now that
SEVState is embedded in SevGuestState we can just access the original copy
directly.
Signed-off-by: David Gibson
Reviewed-by: Philippe
At the moment this is a purely passive object which is just a container for
information used elsewhere, hence the name. I'm going to change that
though, so as a preliminary rename it to SevGuestState.
That name risks confusion with both SEVState and SevState, but I'll be
working on that in
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote:
>
> Hello David,
>
> David Gibson writes:
>
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security
Neither QSevGuestInfo nor SEVState (not to be confused with SevState) is
used anywhere outside target/i386/sev.c, so they might as well live in
there rather than in a (somewhat) exposed header.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
This series has an assortment of cleanups to the AMD SEV memory
encryption code. Amongst other things it:
* Removes the confusion between struct SEVState and enum SevState
* Reduces use of global variables
* Unifies some ad-hoc structures with an existing QOM object
I made these changes
On Thu, Jun 04, 2020 at 08:19:41AM +0200, Thomas Huth wrote:
> On 04/06/2020 07.56, David Gibson wrote:
> > On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
> >> On 5/20/20 8:43 PM, David Gibson wrote:
> >>> +++ b/include/hw/boards.h
> >>> @@ -12,6 +12,8 @@
> >>> #include
This structure is nothing but an empty wrapper around the parent class,
which by QOM conventions means we don't need it at all.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/i386/sev.c | 1 -
target/i386/sev_i386.h | 5 -
2
Currently SevGuestState contains only configuration information. For
runtime state another non-QOM struct SEVState is allocated separately.
Simplify things by instead embedding the SEVState structure in
SevGuestState.
Signed-off-by: David Gibson
Reviewed-by: Richard Henderson
Reviewed-by:
On 06/04/2020 11:22 AM, Richard Henderson wrote:
On 6/3/20 7:58 PM, Wei Wang wrote:
It is possible that encoded_size==0, but unencoded_size !=0. For example,
a page is written with the same data that it already has.
That really contains 0 bytes?
Not even the ones that say "same data"?
Yes.
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> There's no need to read VMCS twice, instruction length is already
> available in ins_len.
>
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/hvf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/i386/hvf/hvf.c
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> They're either declared elsewhere or have no use.
>
> While at it, rename _hvf_cpu_synchronize_post_init() to
> do_hvf_cpu_synchronize_post_init().
>
> Signed-off-by: Roman Bolshakov
> ---
> include/sysemu/hvf.h | 22 --
>
> -Original Message-
> From: Zhanghailiang
> Sent: Wednesday, June 3, 2020 5:39 PM
> To: Zhang, Chen ; Dr . David Alan Gilbert
> ; Juan Quintela ; qemu-dev
>
> Cc: Zhang Chen ; Jason Wang
>
> Subject: RE: [PATCH 3/3] migration/colo: Merge multi checkpoint request
> into one.
>
> >
On 5/28/20 9:37 PM, Roman Bolshakov wrote:
> Signed-off-by: Roman Bolshakov
> ---
> target/i386/hvf/x86.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
> index c95d5b2116..56fcde13c6 100644
> --- a/target/i386/hvf/x86.h
> +++
On 6/3/20 4:52 PM, Guenter Roeck wrote:
> Set vendor property to IMX to enable IMX specific functionality
> in sdhci code.
>
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Guenter Roeck
> ---
> v2: Added missing error checks
> Added Philippe's Tested-by: tag
>
> hw/arm/fsl-imx25.c
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote:
>
> Hello David,
>
> David Gibson writes:
>
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security
Patch posted:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00856.html
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878628
Title:
On 04/06/2020 07.56, David Gibson wrote:
> On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
>> On 5/20/20 8:43 PM, David Gibson wrote:
>>> +++ b/include/hw/boards.h
>>> @@ -12,6 +12,8 @@
>>> #include "qom/object.h"
>>> #include "hw/core/cpu.h"
>>>
>>> +typedef struct
On Mon, May 25, 2020 at 12:26:55PM +0200, Greg Kurz wrote:
>
> s/encrption/encryption
Fixed.
> On Thu, 21 May 2020 13:42:57 +1000
> David Gibson wrote:
>
> > At the moment AMD SEV sets a special function pointer, plus an opaque
> > handle in KVMState to let things know how to encrypt guest
On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote:
> * Sean Christopherson (sean.j.christopher...@intel.com) wrote:
> > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote:
> > > A number of hardware platforms are implementing mechanisms whereby the
> > > hypervisor
On Fri, May 29, 2020 at 12:59:40AM -0700, Ram Pai wrote:
> On Thu, May 21, 2020 at 01:43:03PM +1000, David Gibson wrote:
> > Some upcoming POWER machines have a system called PEF (Protected
> > Execution Framework) which uses a small ultravisor to allow guests to
>
> Framework -> Facility
>
> >
On Fri, May 29, 2020 at 11:09:41AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/21/20 5:42 AM, David Gibson wrote:
> > Currently SevGuestState contains only configuration information. For
> > runtime state another non-QOM struct SEVState is allocated separately.
> >
> > Simplify things by instead
On Fri, May 29, 2020 at 03:19:26PM -0700, Sean Christopherson wrote:
> On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote:
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate
On Mon, Jun 01, 2020 at 08:54:42PM -0700, Richard Henderson wrote:
> On 5/20/20 8:43 PM, David Gibson wrote:
> > +++ b/include/hw/boards.h
> > @@ -12,6 +12,8 @@
> > #include "qom/object.h"
> > #include "hw/core/cpu.h"
> >
> > +typedef struct GuestMemoryProtection GuestMemoryProtection;
> > +
>
On 6/4/20 5:45 AM, Richard Henderson wrote:
> Clang 10 enables this by default with -Wtype-limit.
>
> All of the instances flagged by this Werror so far have been
> cases in which we really do want the compiler to optimize away
> the test completely. Disabling the warning will avoid having
> to
Patch posted:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg706322.html
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878627
Title:
On 6/4/20 12:13 AM, BALATON Zoltan wrote:
> On Thu, 4 Jun 2020, P J P wrote:
>> From: Prasad J Pandit
>>
>> While reading PCI configuration bytes, a guest may send an
>> address towards the end of the configuration space. It may lead
>> to an OOB access issue. Assert that 'address + len' is
301 - 364 of 364 matches
Mail list logo
