On Sun, Sep 12, 2021 at 12:07 AM Philipp Tomsich
wrote:
>
> The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
> orc.b instruction (equivalent to the orc.b pseudo-instruction built on
> gorci from pre-0.93 draft-B) is available, mainly targeting
> string-processing workloads.
>
> Th
Fixes: 5dd1f02b4bc2f2c2ef3a2adfd8a412c8c8769085
Signed-off-by: Markus Armbruster
---
qemu-options.hx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 8f603cc7e6..27e7b9a77c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3188,7 +31
On Mon, 27 Sep 2021 18:50:40 +0200
Cédric Le Goater wrote:
> On 9/24/21 19:13, Greg Kurz wrote:
> > On Fri, 24 Sep 2021 16:58:00 +0200
> > Cédric Le Goater wrote:
> >
> >> [ ... ]
> >>
> The changes only impact KVM support since we are deferring the IRQ
> initialization at the KVM lev
On Fri, Jul 2, 2021 at 3:17 PM Alistair Francis
wrote:
> On Fri, Jul 2, 2021 at 4:11 PM LIU Zhiwei wrote:
> >
> >
> > On 2021/7/2 下午1:38, Alistair Francis wrote:
> > > On Thu, Jul 1, 2021 at 6:45 PM Frank Chang
> wrote:
> > >> LIU Zhiwei 於 2021年4月20日 週二 上午8:49寫道：
> > >>>
> > >>> On 2021/4/20 上
Hello Team,
Would you please give me some suggestions on how I should proceed to build
an IOT (Internet of Things) emulator ? What aspects do I need to consider
? IOT can be anything like a smart light ,smart bulb ,smart lock ,etc.
Here smart means that the device can be controlled via the intern
On Tue, Sep 28, 2021 at 09:14:49AM +0200, Markus Armbruster wrote:
> Fixes: 5dd1f02b4bc2f2c2ef3a2adfd8a412c8c8769085
> Signed-off-by: Markus Armbruster
> ---
> qemu-options.hx | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Daniel P. Berrangé
Regards,
Daniel
--
|: https:
On Mon, Sep 27, 2021 at 05:17:01PM +, Raphael Norwitz wrote:
> In the vhost-user-blk-test, as of now there is nothing stoping
> vhost-user-blk in QEMU writing to the socket right after forking off the
> storage daemon before it has a chance to come up properly, leaving the
> test hanging foreve
Since the removal of the generic 'qmp_change' command, one can no longer replace
the 'default' VNC display listen address at runtime (AFAIK). For our users who
need to set up a secondary VNC access port, this means configuring a second VNC
display (in addition to our standard one for web-access), b
It is possible to specify more than one VNC server on the command line,
either with an explicit ID or the auto-generated ones à la "default",
"vnc2", "vnc3", ...
It is not possible to change the password on one of these extra VNC
displays though. Fix this by adding a "display" parameter to the
"se
Adds support for the "-xS" parameter type, where "-x" denotes a flag
name and the "S" suffix indicates that this flag is supposed to take an
arbitrary string parameter.
These parameters are always optional, the entry in the qdict will be
omitted if the flag is not given.
Reviewed-by: Eric Blake
Le 28/09/2021 à 09:14, Markus Armbruster a écrit :
> Fixes: 5dd1f02b4bc2f2c2ef3a2adfd8a412c8c8769085
> Signed-off-by: Markus Armbruster
> ---
> qemu-options.hx | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 8f603cc7e6..27e7b9a77
On Mon, 27 Sept 2021 at 21:12, Simon Glass wrote:
> I think you are misunderstanding my patch and that may be the problem here.
>
> Where QEMU is provided with a dtb (-dtb) it uses that and passes it
> on. This is absolutely fine and I have tested that this works well
> with U-Boot. No issues.
>
>
On Sun, Sep 26, 2021 at 8:53 PM Bin Meng wrote:
>
> The category of sifive_uart device is not set. Put it into the
> 'input' category.
>
> Signed-off-by: Bin Meng
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
>
> hw/char/sifive_uart.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff
On Tue, 28 Sept 2021 at 03:00, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/nios2/target_signal.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/linux-user/nios2/target_signal.h
> b/linux-user/nios2/target_signal.h
> index aebf749f12..fe266c4c51
There is one example of -smp CLI in qemu-options.hx currently
using "-smp 2" and assuming that there will be 2 sockets.
However now the actually calculation logic of missing sockets
and cores is not immutable, we should use more explicit CLIs
like "-smp 2,sockets=2" if we want multiple sockets.
Si
On 03/09/21 10:13, Thomas Huth wrote:
There is no reason why VNC should always be enabled and not be set to
the default value. We already switched the setting in the "configure"
script in commit 3a6a1256d4 ("configure: Allow vnc to get disabled with
--without-default-features"), so let's do that
There are two places found related to -smp that may need to be fixed
when reading qemu-options.hx. And after searching other Doc files,
there hasn't been any other similar issues.
Yanan Wang (2):
qemu-options: Tweak [,maxcpus=cpus] to [,maxcpus=maxcpus]
qemu-options: Add missing "sockets=2" to
In qemu-option.hx, there is "-smp [[cpus=]n][,maxcpus=cpus]..." in the
DEF part, and "-smp [[cpus=]n][,maxcpus=maxcpus]..." in the RST part.
Obviously the later is right, let's fix the previous one.
Signed-off-by: Yanan Wang
---
qemu-options.hx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On Tue, 28 Sept 2021 at 03:00, Richard Henderson
wrote:
>
> Mirror what the kernel does in arch/arm/kernel/signal.h,
> using the old sigframe struct in the rt sigframe struct.
>
> Update the trampoline code to match the kernel: this uses
> sp-relative accesses rather than pc-relative.
>
> Copy the
On Tue, Sep 28, 2021 at 11:57:42AM +0800, Yanan Wang wrote:
> In the SMP configuration, we should either provide a topology
> parameter with a reasonable value (greater than zero) or just
> omit it and QEMU will compute the missing value.
>
> The users shouldn't provide a configuration with any pa
On Tue, Sep 28, 2021 at 11:57:43AM +0800, Yanan Wang wrote:
> To pave the way for the functional improvement in later patches,
> make some refactor/cleanup for the smp parsers, including using
> local maxcpus instead of ms->smp.max_cpus in the calculation,
> defaulting dies to 0 initially like othe
On Tue, Sep 28, 2021 at 11:57:44AM +0800, Yanan Wang wrote:
> We are currently using maxcpus to calculate the omitted sockets
> but using cpus to calculate the omitted cores/threads. This makes
> cmdlines like:
> -smp cpus=8,maxcpus=16
> -smp cpus=8,cores=4,maxcpus=16
> -smp cpus=8,threads=2,
On Tue, Sep 28, 2021 at 11:57:45AM +0800, Yanan Wang wrote:
> Currently we directly calculate the omitted cpus based on the given
> incomplete collection of parameters. This makes some cmdlines like:
> -smp maxcpus=16
> -smp sockets=2,maxcpus=16
> -smp sockets=2,dies=2,maxcpus=16
> -smp soc
On Tue, Sep 28, 2021 at 11:57:46AM +0800, Yanan Wang wrote:
> We have two requirements for a valid SMP configuration:
> the product of "sockets * cores * threads" must represent all the
> possible cpus, i.e., max_cpus, and then must include the initially
> present cpus, i.e., smp_cpus.
>
> So we o
On 28/09/21 07:13, Gerd Hoffmann wrote:
@@ -212,6 +212,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_RESOURCE_BLOB);
}
+features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
This needs a config option, simliar to the othe
On Tue, Sep 28, 2021 at 11:57:47AM +0800, Yanan Wang wrote:
> Since commit 80d7835749 (qemu-options: rewrite help for -smp options),
> the preference of sockets/cores in -smp parsing is considered liable
> to change, and actually we are going to change it in a coming commit.
> So it'll be more stab
On Tue, Sep 28, 2021 at 11:57:48AM +0800, Yanan Wang wrote:
> Since commit 80d7835749 (qemu-options: rewrite help for -smp options),
> the preference of sockets/cores in -smp parsing is considered liable
> to change, and actually we are going to change it in a coming commit.
> So it'll be more stab
On Tue, Sep 28, 2021 at 11:57:49AM +0800, Yanan Wang wrote:
> In the real SMP hardware topology world, it's much more likely that
> we have high cores-per-socket counts and few sockets totally. While
> the current preference of sockets over cores in smp parsing results
> in a virtual cpu topology w
On Tue, Sep 28, 2021 at 11:57:51AM +0800, Yanan Wang wrote:
> Now that all the possible topology parameters are integrated in struct
> CpuTopology, tweak the order of topology members to be "cpus/sockets/
> dies/cores/threads/maxcpus" for readability and consistency. We also
> tweak the comment by
On Tue, Sep 28, 2021 at 11:57:50AM +0800, Yanan Wang wrote:
> In the sanity-check of smp_cpus and max_cpus against mc in function
> machine_set_smp(), we are now using ms->smp.max_cpus for the check
> but using current_machine->smp.max_cpus in the error message.
> Tweak this by uniformly using the
On Tue, Sep 28, 2021 at 11:57:53AM +0800, Yanan Wang wrote:
> Now we have a generic smp parser for all arches, and there will
> not be any other arch specific ones, so let's remove the callback
> from MachineClass and call the parser directly.
>
> Signed-off-by: Yanan Wang
> Reviewed-by: Andrew J
On Tue, Sep 28, 2021 at 11:57:54AM +0800, Yanan Wang wrote:
> Now we have a common structure SMPCompatProps used to store information
> about SMP compatibility stuff, so we can also move smp_prefer_sockets
> there for cleaner code.
>
> No functional change intended.
>
> Signed-off-by: Yanan Wang
On Tue, Sep 28, 2021 at 11:57:52AM +0800, Yanan Wang wrote:
> Currently the only difference between smp_parse and pc_smp_parse
> is the support of dies parameter and the related error reporting.
> With some arch compat variables like "bool dies_supported", we can
> make smp_parse generic enough for
ping
https://patchew.org/QEMU/20210831192720.33406-1-yaroshchuk2...@gmail.com/
вт, 31 авг. 2021 г. в 22:27, Vladislav Yaroshchuk :
> macOS provides networking API for VMs called vmnet.framework.
> I tried to add it as a network backend. All three modes are supported:
>
> -shared:
> allows the g
Hi Peter,
On Mon, 27 Sept 2021 at 18:39, Peter Maydell
wrote:
> I thought we'd agreed to implement the whole of the auto-increment
> logic, not just for specific registers ?
>
Thanks again for the feedback. Dealing with one register value at a time
(versus a buffer of response values) does simp
On Tue, Sep 28, 2021 at 11:57:55AM +0800, Yanan Wang wrote:
> Put both sanity-check of the input SMP configuration and sanity-check
> of the output SMP configuration uniformly in the generic parser. Then
> machine_set_smp() will become cleaner, also all the invalid scenarios
> can be tested only by
On 9/28/21 11:31, Yanan Wang wrote:
In qemu-option.hx, there is "-smp [[cpus=]n][,maxcpus=cpus]..." in the
DEF part, and "-smp [[cpus=]n][,maxcpus=maxcpus]..." in the RST part.
Obviously the later is right, let's fix the previous one.
Signed-off-by: Yanan Wang
---
Reviewed-by: Damien Hedde
On 9/28/21 11:31, Yanan Wang wrote:
> There is one example of -smp CLI in qemu-options.hx currently
> using "-smp 2" and assuming that there will be 2 sockets.
> However now the actually calculation logic of missing sockets
> and cores is not immutable, we should use more explicit CLIs
> like "-smp
On 9/28/21 05:57, Yanan Wang wrote:
> We have two requirements for a valid SMP configuration:
> the product of "sockets * cores * threads" must represent all the
> possible cpus, i.e., max_cpus, and then must include the initially
> present cpus, i.e., smp_cpus.
>
> So we only need to ensure 1) "s
On 9/28/21 05:57, Yanan Wang wrote:
> In the sanity-check of smp_cpus and max_cpus against mc in function
> machine_set_smp(), we are now using ms->smp.max_cpus for the check
> but using current_machine->smp.max_cpus in the error message.
> Tweak this by uniformly using the local ms.
>
> Signed-of
On 9/28/21 05:57, Yanan Wang wrote:
> Since commit 80d7835749 (qemu-options: rewrite help for -smp options),
> the preference of sockets/cores in -smp parsing is considered liable
> to change, and actually we are going to change it in a coming commit.
> So it'll be more stable to use detailed -smp
On 9/28/21 05:57, Yanan Wang wrote:
> Since commit 80d7835749 (qemu-options: rewrite help for -smp options),
> the preference of sockets/cores in -smp parsing is considered liable
> to change, and actually we are going to change it in a coming commit.
> So it'll be more stable to use detailed -smp
On 9/28/21 05:24, p...@fb.com wrote:
From: Peter Delevoryas
Some of the pin declarations in the Aspeed GPIO module were incorrect,
probably because of confusion over which bits in the input and output
uint32_t's correspond to which groups in the label array. Since the
uint32_t literals are i
On 9/28/21 05:57, Yanan Wang wrote:
> Currently the only difference between smp_parse and pc_smp_parse
> is the support of dies parameter and the related error reporting.
> With some arch compat variables like "bool dies_supported", we can
> make smp_parse generic enough for all arches and the PC s
On 2021/9/28 18:46, Philippe Mathieu-Daudé wrote:
On 9/28/21 11:31, Yanan Wang wrote:
There is one example of -smp CLI in qemu-options.hx currently
using "-smp 2" and assuming that there will be 2 sockets.
However now the actually calculation logic of missing sockets
and cores is not immutable
On 9/28/21 05:57, Yanan Wang wrote:
> Now that all the possible topology parameters are integrated in struct
> CpuTopology, tweak the order of topology members to be "cpus/sockets/
> dies/cores/threads/maxcpus" for readability and consistency. We also
> tweak the comment by adding explanation of di
On Tue, Sep 28, 2021 at 12:57:21PM +0200, Philippe Mathieu-Daudé wrote:
> On 9/28/21 05:57, Yanan Wang wrote:
> > Currently the only difference between smp_parse and pc_smp_parse
> > is the support of dies parameter and the related error reporting.
> > With some arch compat variables like "bool die
On 9/28/21 05:57, Yanan Wang wrote:
> Now we have a generic smp parser for all arches, and there will
> not be any other arch specific ones, so let's remove the callback
> from MachineClass and call the parser directly.
>
> Signed-off-by: Yanan Wang
> Reviewed-by: Andrew Jones
> ---
> hw/core/m
On 9/28/21 05:57, Yanan Wang wrote:
> Put both sanity-check of the input SMP configuration and sanity-check
> of the output SMP configuration uniformly in the generic parser. Then
> machine_set_smp() will become cleaner, also all the invalid scenarios
> can be tested only by calling the parser.
>
On Tue, Sep 28, 2021 at 06:58:20PM +0800, wangyanan (Y) wrote:
>
> On 2021/9/28 18:46, Philippe Mathieu-Daudé wrote:
> > On 9/28/21 11:31, Yanan Wang wrote:
> > > There is one example of -smp CLI in qemu-options.hx currently
> > > using "-smp 2" and assuming that there will be 2 sockets.
> > > How
On 9/28/21 12:58, Daniel P. Berrangé wrote:
> On Tue, Sep 28, 2021 at 12:57:21PM +0200, Philippe Mathieu-Daudé wrote:
>> On 9/28/21 05:57, Yanan Wang wrote:
>>> Currently the only difference between smp_parse and pc_smp_parse
>>> is the support of dies parameter and the related error reporting.
>>>
On 2021/9/28 18:58, Daniel P. Berrangé wrote:
On Tue, Sep 28, 2021 at 12:57:21PM +0200, Philippe Mathieu-Daudé wrote:
On 9/28/21 05:57, Yanan Wang wrote:
Currently the only difference between smp_parse and pc_smp_parse
is the support of dies parameter and the related error reporting.
With som
On 2021/9/28 17:58, Daniel P. Berrangé wrote:
On Tue, Sep 28, 2021 at 11:57:42AM +0800, Yanan Wang wrote:
In the SMP configuration, we should either provide a topology
parameter with a reasonable value (greater than zero) or just
omit it and QEMU will compute the missing value.
The users shou
On 2021/9/28 19:01, Philippe Mathieu-Daudé wrote:
On 9/28/21 05:57, Yanan Wang wrote:
Put both sanity-check of the input SMP configuration and sanity-check
of the output SMP configuration uniformly in the generic parser. Then
machine_set_smp() will become cleaner, also all the invalid scenario
In some cases for large size VM, memory_global_dirty_log_sync() and
ramblock_sync_dirty_bitmap() combined can take more than 1 sec. As a
result diff of end_time and rs->time_last_bitmap_sync can be more
than 1 sec even when migration_bitmap_sync is called the first time,
setting up the throttle in
On Thu, Sep 02, 2021 at 03:09:15PM +0200, Richard Henderson wrote:
> On 8/31/21 2:15 PM, Gerd Hoffmann wrote:
> > diff --git a/target/i386/helper.c b/target/i386/helper.c
> > index 533b29cb91b6..100add713c5d 100644
> > --- a/target/i386/helper.c
> > +++ b/target/i386/helper.c
> > @@ -103,7 +103,7 @
On Tuesday, 14 September, 2021, 07:00:27 pm IST, P J P
wrote:
>* Thanks so much for restarting this thread. I've been at it intermittently
>last few
> months, thinking about how could we annotate the source/module objects.
>
> -> [*] https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04642
Hi!
On Mon, Sep 27, 2021 at 8:55 PM John Snow wrote:
> Hiya,
>
> I'd like to propose that at least the three of us arrange a time to have a
> meeting where we discuss our plans and ideas for QAPI going forward,
> including rust, python, and golang extensions to the QAPI generator, what
> we hope
On 2021/9/28 19:01, Daniel P. Berrangé wrote:
On Tue, Sep 28, 2021 at 06:58:20PM +0800, wangyanan (Y) wrote:
On 2021/9/28 18:46, Philippe Mathieu-Daudé wrote:
On 9/28/21 11:31, Yanan Wang wrote:
There is one example of -smp CLI in qemu-options.hx currently
using "-smp 2" and assuming that th
On 8/31/21 14:15, Gerd Hoffmann wrote:
> Add TCGModuleOps struct, empty for now, followup patches will fill it.
> This struct has pointers for tcg functions which are called by core
> qemu.
>
> The struct is initialized (at compile time) with pointers to stub
> functions. When the tcg module load
On 9/28/21 13:42, wangyanan (Y) wrote:
>
> On 2021/9/28 19:01, Daniel P. Berrangé wrote:
>> On Tue, Sep 28, 2021 at 06:58:20PM +0800, wangyanan (Y) wrote:
>>> On 2021/9/28 18:46, Philippe Mathieu-Daudé wrote:
On 9/28/21 11:31, Yanan Wang wrote:
> There is one example of -smp CLI in qemu-o
On Montag, 27. September 2021 17:44:59 CEST Christian Schoenebeck wrote:
> Two pure refactoring code cleanup patches regarding iounit calculation, no
> behaviour change.
>
> Christian Schoenebeck (2):
> 9pfs: deduplicate iounit code
> 9pfs: simplify blksize_to_iounit()
>
> hw/9pfs/9p.c | 41
Hi,
> > This needs a config option, simliar to the other features. It is a
> > guest-visible change so we must be able to turn it off for live
> > migration compatibility reasons. We also need a compat property to
> > turn it off by default for 6.1 + older machine types.
>
> Could you give me
On Tue, 28 Sept 2021 at 11:36, Kevin Townsend wrote:
>
> Hi Peter,
>
> On Mon, 27 Sept 2021 at 18:39, Peter Maydell wrote:
>>
>> I thought we'd agreed to implement the whole of the auto-increment
>> logic, not just for specific registers ?
>
>
> Thanks again for the feedback. Dealing with one reg
On Mon, 27 Sept 2021 at 18:43, Philippe Mathieu-Daudé wrote:
>
> The following changes since commit de8ed1055c2ce18c95f597eb10df360dcb534f99:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-25-v2'
> into staging (2021-09-27 15:03:42 +0100)
>
> are available in the Git re
There is one numa config example in qemu-options.hx currently
using "-smp 2" and assuming that there will be 2 sockets and
2 cpus totally. However now the actual calculation logic of
missing sockets and cores is not immutable and is considered
liable to change. Although we will get maxcpus=2 finall
In qemu-option.hx, there is "-smp [[cpus=]n][,maxcpus=cpus]..." in the
DEF part, and "-smp [[cpus=]n][,maxcpus=maxcpus]..." in the RST part.
Obviously the later is right, let's fix the previous one.
Signed-off-by: Yanan Wang
Reviewed-by: Damien Hedde
---
qemu-options.hx | 2 +-
1 file changed,
Hi,
> > +struct TCGModuleOps {
> > +};
> > +extern struct TCGModuleOps tcg;
>
> TCG functions taking a CPUState argument should reside in
> CPUClass's AccelCPUClass/TCGCPUOps, not a global struct.
It's not that easy. Tried that first, but using TCGCPUOps outside cpu
code doesn't work.
take c
v1->v2:
- update the subject and commit message of patch 2/2.
- add R-bs from Damien and Philippe. Thanks.
There are two places found related to -smp that may need to be fixed
when reading qemu-options.hx. And after searching other Doc files,
there hasn't been any other similar issues.
Yanan Wang
Philippe Mathieu-Daudé writes:
> On 9/28/21 05:57, Yanan Wang wrote:
>> Currently the only difference between smp_parse and pc_smp_parse
>> is the support of dies parameter and the related error reporting.
>> With some arch compat variables like "bool dies_supported", we can
>> make smp_parse gen
On Montag, 27. September 2021 12:59:40 CEST Greg Kurz wrote:
> On Mon, 27 Sep 2021 12:35:16 +0200
>
> Christian Schoenebeck wrote:
> > On Dienstag, 31. August 2021 14:25:04 CEST Christian Schoenebeck wrote:
> > > On Dienstag, 31. August 2021 13:58:02 CEST Greg Kurz wrote:
> > > > On Thu, 26 Aug 2
On 9/28/21 5:31 AM, Peter Maydell wrote:
+uint32_t *host_rc = g2h_untagged(retcode);
...but here we treat it as a normal guest address that we can
convert into a host address and dereference. If the signal handler
is being entered in Thumb mode this will be a misaligned pointer.
Oops,
On Tue, Sep 28, 2021 at 08:11:34PM +0800, Yanan Wang wrote:
> There is one numa config example in qemu-options.hx currently
> using "-smp 2" and assuming that there will be 2 sockets and
> 2 cpus totally. However now the actual calculation logic of
> missing sockets and cores is not immutable and i
On Tue, Sep 28, 2021 at 08:11:33PM +0800, Yanan Wang wrote:
> In qemu-option.hx, there is "-smp [[cpus=]n][,maxcpus=cpus]..." in the
> DEF part, and "-smp [[cpus=]n][,maxcpus=maxcpus]..." in the RST part.
> Obviously the later is right, let's fix the previous one.
>
> Signed-off-by: Yanan Wang
>
On 9/28/21 7:32 AM, Gerd Hoffmann wrote:
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 608d768a4371..72e4e3b5bb89 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -160,7 +160,9 @@ void tlb_flush_page_all_cpus_synced(CPUState *src,
target_ulong addr);
From: Yang Zhong
Add new CONFIG_SGX for sgx support in the Qemu, and the Kconfig
default enable sgx in the i386 platform.
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-32-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
configs/devices/i386-softmmu/default.mak | 1 +
hw/i3
From: Sean Christopherson
Add a new RAMBlock flag to denote "protected" memory, i.e. memory that
looks and acts like RAM but is inaccessible via normal mechanisms,
including DMA. Use the flag to skip protected memory regions when
mapping RAM for DMA in VFIO.
Signed-off-by: Sean Christopherson
From: Sean Christopherson
EPC (Enclave Page Cahe) 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
From: Sean Christopherson
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
h
From: Sean Christopherson
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
bee
From: Sean Christopherson
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
The following changes since commit 14f02d8a9ec1746823c106933a4c8f062f9e0f95:
Merge remote-tracking branch
'remotes/philmd/tags/integration-testing-20210927' into staging (2021-09-27
19:52:43 +0100)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstrea
From: Sean Christopherson
If the guest want to fully use SGX, the guest needs to be able to
access provisioning key. Add a new KVM_CAP_SGX_ATTRIBUTE to KVM to
support provisioning key to KVM guests.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-
From: Sean Christopherson
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 EP
From: Yang Zhong
Since there is no fill_device_info() callback support, and when we
execute "info memory-devices" command in the monitor, the segfault
will be found.
This patch will add this callback support and "info memory-devices"
will show sgx epc memory exposed to guest. The result as below
From: Sean Christopherson
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 e
From: Yang Zhong
Add the new 'memory-backend-epc' user creatable QOM object in
the ObjectOptions to support SGX since v6.1, or the sgx backend
object cannot bootup.
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-4-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
qapi/qom.js
From: Sean Christopherson
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
From: Sean Christopherson
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 a
From: Sean Christopherson
CPUID leaf 12_0_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
Signed
From: Peter Xu
Provide a name field for all the memory listeners. It can be used to identify
which memory listener is which.
Signed-off-by: Peter Xu
Reviewed-by: David Hildenbrand
Message-Id: <20210817013553.30584-2-pet...@redhat.com>
Signed-off-by: Paolo Bonzini
---
accel/hvf/hvf-accel-ops
From: Sean Christopherson
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.
For multiple virtual EPC sections, we just put them together physically
contiguous for the simplicity
From: Sean Christopherson
Request SGX an SGX Launch Control to be enabled in FEATURE_CONTROL
when the features are exposed to the guest. Our design is the SGX
Launch Control bit will be unconditionally set in FEATURE_CONTROL,
which is unlike host bios.
Signed-off-by: Sean Christopherson
Signed-
Skip the test if bzip2 is not available, and run it after they are
uncompressed.
Signed-off-by: Paolo Bonzini
Message-Id: <20210923105529.3845741-2-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini
---
pc-bios/meson.build | 3 ++-
tests/qtest/meson.build | 6 +++---
2 files changed, 5 inser
From: Sean Christopherson
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.
ult
From: Sean Christopherson
SGX adds multiple flags to FEATURE_CONTROL to enable SGX and Flexible
Launch Control.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-12-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
target/i386/kvm/kvm.c | 5 +
From: Peter Xu
Trace at memory_region_sync_dirty_bitmap() for log_sync() or global_log_sync()
on memory regions. One trace line should suffice when it finishes, so as to
estimate the time used for each log sync process.
Signed-off-by: Peter Xu
Message-Id: <20210817013706.30986-1-pet...@redhat.
From: Sean Christopherson
Enable SGX EPC virtualization, which is currently only support by KVM.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-21-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
hw/i386/pc_q35.c | 1 +
1 file changed, 1
The edk2 firmware blobs are needed to run bios-tables-test. Unpack
them if any UEFI-enabled target is selected, so that the test can run.
This is a bit more than is actually necessary, since bios-tables-test
does not run for all UEFI-enabled targets, but it is the easiest
way to write this logic.
From: Sean Christopherson
On real hardware, on systems that supports SGX Launch Control, those
MSRs are initialized to digest of Intel's signing key; on systems that
don't support SGX Launch Control, those MSRs are not available but
hardware always uses digest of Intel's signing key in EINIT.
KV
1 - 100 of 226 matches
Mail list logo
