[Qemu-devel] [PATCH] Update references of "struct ucontext" to "ucontext_t"
Glibc used to have:
typedef struct ucontext { ... } ucontext_t;
Glibc now has:
typedef struct ucontext_t { ... } ucontext_t;
However, Qemu used "struct ucontext" in declarations. This is a
private name and compatiblity cannot be guaranteed. This patch
updates Qemu to only use the standardized type name.
Signed-off-by: Nathaniel McCallum
---
linux-user/host/aarch64/hostdep.h | 2 +-
linux-user/host/arm/hostdep.h | 2 +-
linux-user/host/i386/hostdep.h| 2 +-
linux-user/host/ppc64/hostdep.h | 2 +-
linux-user/host/s390x/hostdep.h | 2 +-
linux-user/host/x86_64/hostdep.h | 2 +-
linux-user/signal.c | 10 +-
tests/tcg/test-i386.c | 4 ++--
user-exec.c | 18 +-
9 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/linux-user/host/aarch64/hostdep.h
b/linux-user/host/aarch64/hostdep.h
index 64f75cef49..a8d41a21ad 100644
--- a/linux-user/host/aarch64/hostdep.h
+++ b/linux-user/host/aarch64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
__u64 *pcreg = &uc->uc_mcontext.pc;
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/arm/hostdep.h b/linux-user/host/arm/hostdep.h
index 5c1ae60120..9276fe6ceb 100644
--- a/linux-user/host/arm/hostdep.h
+++ b/linux-user/host/arm/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
unsigned long *pcreg = &uc->uc_mcontext.arm_pc;
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/i386/hostdep.h b/linux-user/host/i386/hostdep.h
index d834bd80ea..073be74d87 100644
--- a/linux-user/host/i386/hostdep.h
+++ b/linux-user/host/i386/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
greg_t *pcreg = &uc->uc_mcontext.gregs[REG_EIP];
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/ppc64/hostdep.h b/linux-user/host/ppc64/hostdep.h
index 0b0f5f7821..98979ad917 100644
--- a/linux-user/host/ppc64/hostdep.h
+++ b/linux-user/host/ppc64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
unsigned long *pcreg = &uc->uc_mcontext.gp_regs[PT_NIP];
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/s390x/hostdep.h b/linux-user/host/s390x/hostdep.h
index 6f9da9c608..4f0171f36f 100644
--- a/linux-user/host/s390x/hostdep.h
+++ b/linux-user/host/s390x/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
unsigned long *pcreg = &uc->uc_mcontext.psw.addr;
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/x86_64/hostdep.h b/linux-user/host/x86_64/hostdep.h
index 3b4259633e..a4fefb5114 100644
--- a/linux-user/host/x86_64/hostdep.h
+++ b/linux-user/host/x86_64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
/* Adjust the signal context to rewind out of safe-syscall if we're in it */
static inline void rewind_if_in_safe_syscall(void *puc)
{
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
greg_t *pcreg = &uc->uc_mcontext.gregs[REG_RIP];
if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 3d18d1b3ee..2c55a4f600 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -3346,7 +3346,7 @@ static void setup_rt_frame(int sig, struct
target_sigaction *ka,
*
* a0 = signal number
* a1 = pointer to siginfo_t
-* a2 = pointer to struct ucontext
+* a2 = pointer to ucontext_t
*
* $25 and PC point to the signal handler, $29 points to the
* struct sigframe.
@@ -3733,7 +3733,7 @@ struct target_signal_frame {
struct rt_signal_frame {
siginfo_t info;
-struct ucontext uc;
+ucontext_t uc;
uint32_t tramp[2];
};
@@ -3949,7 +3949,7 @@ struct rt_signal_frame {
siginfo_t *pinfo;
void *puc;
siginfo_t info;
-struct ucontext uc;
+ucontext_t uc;
uint16_t retcode[4
Re: [Qemu-devel] [PATCH] Update references of "struct ucontext" to "ucontext_t"
Yes, it is a dup. Sorry for the noise.
On Tue, Jul 18, 2017 at 9:03 PM, Eric Blake wrote:
> On 07/18/2017 07:58 PM, Nathaniel McCallum wrote:
>> Glibc used to have:
>>
>>typedef struct ucontext { ... } ucontext_t;
>>
>> Glibc now has:
>>
>>typedef struct ucontext_t { ... } ucontext_t;
>>
>> However, Qemu used "struct ucontext" in declarations. This is a
>> private name and compatiblity cannot be guaranteed. This patch
>> updates Qemu to only use the standardized type name.
>>
>> Signed-off-by: Nathaniel McCallum
>> ---
>
> Looks like this duplicates:
> https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06508.html
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
[Qemu-devel] QCow v2
Mark's notes on the qcow format got me to thinking how useful it would
be to be able to store other information in the qcow image itself. For
instance you could store the configuration for the virtual machine in
the image which could be extracted and then start the virtual machine.
So... I'm proposing that the qcow image be extended to support this
scenario. Something as simple as:
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
uint8_t embedded_data_type;
uint64_t embedded_data_offset;
uint32_t embedded_data_size;
uint32_t mtime;
uint64_t size;
uint8_t cluster_bits;
uint8_t l2_bits;
uint32_t crypt_method;
uint64_t l1_table_offset;
} QCowHeader;
Thus, embedded_data_type is a constant signifying the type of the data.
embedded_data_type could be a string, etc. Of course, there are a million
other ways this could be implemented. The idea being that we could store
more than just backing store.
One possible application could be that you could store config info in
the image and have a qemu-loader app that extracts the info and starts
the virtual machine. Another application could be just misc. metadata:
copyright, contact info, VM version, etc...
I can provide a patch to block-qcow.c if there is interest.
Nathaniel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
On Tue, 2006-07-04 at 11:23 +0200, Fabrice Bellard wrote:
> Hi,
>
> I am not sure it is interesting to store the configuration of the VM in
> the disk image (there can be several disk images for a given VM).
> Moreover, extensions to the qcow header must be added at its end.
Storing the config in the disk image does not preclude:
1. using multiple disk images with a vm
2. using multiple vm's with a single disk image
Nor does it make it more difficult to do any of the above. All it does
is make it easier for the use case of one VM with one image, which is
the vast majority of VM's out there.
In addition, it definitely is interesting to store other random data in
the image. Here is a second proposal:
We have a key/value section that replaces the backing store section:
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
uint64_t key_val_offset; /* was backing_file_offset */
uint32_t key_val_size; /* was backing_file_size */
uint32_t mtime;
uint64_t size;
uint8_t cluster_bits;
uint8_t l2_bits;
uint32_t crypt_method;
uint64_t l1_table_offset;
} QCowHeader;
The above does not change the size of the header. And as such, you can
still read the header off the file and determine how to interpret it
based on the version number.
The key_val section is pairs of null terminated (UTF-8?) strings. The
first string in the pair is the key, the second is the value.
It could handle the current backing store design like this:
"backing_store": ""
> Regarding my current plans, the next qcow evolution will be the support
> for multiple snapshots. Each snapshot will be tagged by a label.
I assume you'll do this with multiple backing stores:
"num_backing_stores" : "2"
"backing_store_0" : ""
"backing_store_0_label": ""
"backing_store_1" : ""
"backing_store_1_label": ""
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] No useful documentation.
A person who is in your position (frustrated for lack of documentation) is actually the most qualified person to write documentation. Feel free to ask any questions you have on this list. Nathaniel On Wed, 2006-07-05 at 21:57 +0100, Daniel Carrera wrote: > Hello, > > I write here because there doesn't seem to be a Bugzilla for qemu and > whoever is responsible for the qemu documentation must be here. > > The documentation is quite worthless. > > I'm sure you don't like hearing that, but consider that it doesn't > actually show the user how get qemu to do what qemu is supposed to di > (ie. run a host OS). Ok, it tells me how to create a blank disk image, > that's great, but how do I create a disk image with something bootable > on it? Sorry, no information on that. I expect that the most typical use > case for qemu is running Windows under Linux, so you'd expect to see > some documentation for that, right? Nope, none. Sure, there are > trouble-shooting tips, but what use are trouble-shooting tips if you > can't even get started? > > I've looked at qemu several times over the past several years. Every > time I get excited at the prospect of migrating people to GNU/Linux by > letting them run the one windows app they need... and every time I hit a > brick wall, as qemu fails to actually do anything useful. > > Try to take this approach: You are writing to a technically competent > user (perhaps a sysadmin) who wants to run Windows under Linux with qemu > (perhaps to migrate some of the company computers). He has a Windows > install CD, he has qemu installed, and is ready to go. Please write > something that this person can use to get Windows running under qemu. > > Cheers, > Daniel. > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] No useful documentation.
To create an empty Hard Drive image do:
qemu-img create
for example:
qemu-img create windows.img 2G
You can also use the preferred ("qcow") image format by doing:
qemu-img create -f qcow windows.img 2G
That gives you the ability to save snapshots, encrypt the image, etc.
Now we'll use this image:
qemu -hda windows.img -cdrom /dev/cdrom -m 256 -boot d
That says:
"-hda windows.img" == Use the file windows.img for the first disk
"-cdrom /dev/cdrom" == Use /dev/cdrom for the CDROM
"-m 256" == Use 256MB of memory
"-boot d" == "Boot off of drive 'd', aka the cdrom"
Nathaniel
On Wed, 2006-07-05 at 22:19 +0100, Daniel Carrera wrote:
> On Wed, 2006-05-07 at 17:12 -0400, Nathaniel McCallum wrote:
> > A person who is in your position (frustrated for lack of documentation)
> > is actually the most qualified person to write documentation. Feel free
> > to ask any questions you have on this list.
>
> I would be happy to contribute a section. First I need to learn how qemu
> works though. Just the basics. On another list someone told me that the
> way qemu works is by first creating a blank image, then booting a CD
> from the virtual machine and installing.
>
> At this point I know how to make a blank image, and I know how to boot a
> CD:
>
> qemu -cdrom /dev/cdrom
>
> Now I need to figure out how to put these together so that if this CD
> can install an operating system, qemu will know to use the blank image I
> made (call it c.img) as a hard drive for its virtual machine.
>
> Could someone tell me how to do that?
>
> I'll be happy to write an intro tutorial for new users with the
> knowledge I gain.
>
> Cheers,
> Daniel.
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
