If "detach" is provided, one thread is created to do the dump work,
while main thread will return immediately. For each GuestPhysBlock,
adding one more field "mr" to points to MemoryRegion that it
belongs, also ref the mr before use.
Signed-off-by: Peter Xu
Reviewed-by: Fam Zheng
---
dump.c
On 12/08/2015 01:38 PM, Sam Bobroff wrote:
On Mon, Dec 07, 2015 at 02:34:37PM +1100, David Gibson wrote:
At the moment all the class_init functions and TypeInfo structures for the
various versioned pseries machine types are open-coded. As more versions
are created this is getting increasingly c
On 12/07/2015 02:34 PM, David Gibson wrote:
98cec76 "machine: Set MachineClass::name automatically" removed the setting
of mc->name for the pseries machine types, since it can be derived
automatically from the type names constructed with MACHINE_TYPE_NAME().
Unfortunately fb0fc8f "spapr: Create
On 12/07/2015 02:34 PM, David Gibson wrote:
pc.h defines a SET_MACHINE_COMPAT macro to make setting up compat_props
for the various PC machine versions less verbose. There's nothing
inherently PC specific about it, though, so move it to boards.h where other
versioned machine types (like pseries-
On 12/07/2015 02:34 PM, David Gibson wrote:
The instance_init() functions for several of the pseries-x.y versioned
machine types explicitly call spapr_machine_initfn(). But that's the
instance_init function for the common parent of all those machine types,
so will already have been called before
On 12/07/2015 02:34 PM, David Gibson wrote:
Currently, the versioned spapr machine types put the machine type version
into the description string. PC does not do this, using just the name
itself to distinguish. Doing the same lets us move setting the description
into the common base class, simp
On 12/07/2015 02:34 PM, David Gibson wrote:
To make the spapr_machine_*_class_init() functions a little less bulky.
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
ind
On 12/07/2015 02:34 PM, David Gibson wrote:
Currently each of the *_class_options() functions for the pseries-2.1 ..
pseries-2.5 machine types are standalone. This will become harder to
maintain as new versions are added.
This patch restructures them similarly to x86 where each function calls
t
On 12/07/2015 02:34 PM, David Gibson wrote:
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 8b8eb18..2d57ab0 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2337,6
On 12/07/2015 02:34 PM, David Gibson wrote:
This tweaks the way the default machine version is controlled, so that
there will be a bit less churn when each new version is introduced.
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 20 ++--
1 file changed, 10 insertions(+), 1
On 12/09/2015 02:30 PM, Alexey Kardashevskiy wrote:
On 12/08/2015 01:38 PM, Sam Bobroff wrote:
On Mon, Dec 07, 2015 at 02:34:37PM +1100, David Gibson wrote:
At the moment all the class_init functions and TypeInfo structures for the
various versioned pseries machine types are open-coded. As mor
On 12/07/2015 02:34 PM, David Gibson wrote:
hw/ppc/spapr.c has a number of definitions related to the various versioned
machine types ("pseries-2.1" .. "pseries-2.5") it defines. These are
mostly arranged by type of function first, then machine version second, and
it's not consistent about wheth
On Mon, Dec 07, 2015 at 11:21:26AM +0100, Thomas Huth wrote:
> On 07/12/15 04:34, David Gibson wrote:
> > hw/ppc/spapr.c has a number of definitions related to the various versioned
> > machine types ("pseries-2.1" .. "pseries-2.5") it defines. These are
> > mostly arranged by type of function fir
Add pci = [ '$VF_BDF1', '$VF_BDF2', '$VF_BDF3'] in
hvm guest configuration file. After the guest boot up,
detach the VFs in sequence by
"xl pci-detach $DOMID $VF_BDF1"
"xl pci-detach $DOMID $VF_BDF2"
"xl pci-detach $DOMID $VF_BDF3"
and reattach the VFs in sequence by
"xl pci-attach $DOMID $VF_B
> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Saturday, 5 December 2015 21:26
> Is this IP just SDHCI? We already model SDHCI in QEMU, see
> hw/sd/sdhci.c. If there are RPi specific features to the SDHCI
> implementation they should be added as optional extensions (probababl
Peter,
Thanks for the feedback on this patch. I agree with all of it, but I do have
one minor quibble...
> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Saturday, 5 December 2015 21:20
> On Thu, Dec 3, 2015 at 10:01 PM, Andrew Baumann
> wrote:
> > --- a/hw/intc/Makefile.ob
> Hi Gerd,
>
> A quick question, does IGD_PASSTHROUGH makes sense for compat machine types?
Unlikely to be used in practice, but I don't feel like creating
different initialization code paths because of that ...
> On the same topic, does machine->igd_gfx_passthru makes sense for all machine
> t
Hi all,
Please correct me if I’m wrong.
I made some changes to IDE emulation (add some extra structures to “struct
IDEState") and want to save these info to files when VM shutdowns. So I can
reload these info from files next time when VM starts. According to my
understanding, one IDEState str
Hi all,
I am trying to boot Windows 8 (x86) on arm host using qemu dynamic
translation.
It is not successfull but Windows xp boots fine.
Any suggest for this issue?
Hi all,
I am trying to boot Windows 8 (x86) on arm host using qemu dynamic
translation.
It is not successfull but Windows xp boots fine.
Any suggest for this issue?
On Wednesday, December 9, 2015, wrote:
> Send Qemu-devel mailing list submissions to
> qemu-devel@nongnu.org
>
> To subscri
On Tue, Dec 8, 2015 at 10:19 PM, Andrew Baumann
wrote:
>> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> Sent: Saturday, 5 December 2015 21:26
>> Is this IP just SDHCI? We already model SDHCI in QEMU, see
>> hw/sd/sdhci.c. If there are RPi specific features to the SDHCI
>> implemen
101 - 121 of 121 matches
Mail list logo
