Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0
On Wed, Mar 03, 2021 at 05:57:45PM -0800, Nick S wrote:
> When you say "instal", do you mean configuring another VM with the same SSD in
> libvirt? I am not actually using the manually compiled version of qemu with
> libvirt, I just grabbed the command line from it and adjusted it a bit to work
> separately. And the libvirt that created it is fairly recent. I can certainly
> change the machine type there if you tell me what you want tested.
Sure, just change it to 5.2.
> This is my
> Windows to go image that I use in all kinds of places and it should be able to
> boot in both UEFI and Bios modes.
>
> On Wed, Mar 3, 2021 at 2:06 PM Michael S. Tsirkin wrote:
>
> OK great, good to know. note it works because you
> specified an old machine type as libvirt does for
> old installed VMs.
>
> My next question then is, what happens if you install
> a new VM? Does it work fine for you then?
>
>
> On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote:
> > This change works perfectly, thank you!
> >
> > On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin
> wrote:
> >
> > Can you try this please:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/
> for_upstream
> >
> > ?
> >
> >
> > On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> > > I found the commit that breaks my VM. Anybody has any background
> on
> why
> > it was
> > > done? The comments are fairly extensive, but they are Mac related
> and I
> > am
> > > running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change
> > definitely
> > > breaks Windows 10. Anything before I can check out, compile and it
> runs
> > fine.
> > > Anything after this commit and it produces that boot device
> inaccessible
> > error.
> > > Reverting this change on the current master also makes it work
> fine.
> > >
> > > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> > > af1b80ae56c9495999e8ccf7b70ef894378de642
> > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > > index b7bc2a..7a5a8b3521 100644
> > > --- a/hw/i386/acpi-build.c
> > > +++ b/hw/i386/acpi-build.c
> > > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> > > dev = aml_device("PCI0");
> > > aml_append(dev, aml_name_decl("_HID", aml_eisaid
> ("PNP0A03")));
> > > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > > aml_append(sb_scope, dev);
> > > aml_append(dsdt, sb_scope);
> > >
> > > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> > > aml_append(dev, aml_name_decl("_HID", aml_eisaid
> ("PNP0A08")));
> > > aml_append(dev, aml_name_decl("_CID", aml_eisaid
> ("PNP0A03")));
> > > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > > aml_append(dev, build_q35_osc_method());
> > > aml_append(sb_scope, dev);
> > > aml_append(dsdt, sb_scope);
> > >
> > > It looks like a regression issue in 5.2.x so I registered a bug
> for
> > it: https:/
> > > /bugs.launchpad.net/qemu/+bug/1917565
> > >
> > >
> > > On Sun, Feb 28, 2021 at 9:13 PM Nick S
> wrote:
> > >
> > >
> > > I have a VM set up on a USB SSD drive that I assign directly
> using
> > linux
> > > device (-blockdev '{"driver":"host_device","filename":"/dev/
> disk/
> > by-id/
> > >
> >
>
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> > >
> >
>
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> > >
> > > I've been using it for a few years now and recently decided to
> > compile the
> > > most recent version of qemu to do some hacking. To my
> surprise,
> when
> > I
> > > compiled the master branch, Windows failed to load with the
> "Boot
> > Device
> > > Inaccessible" error. I went through tags in git and the latest
> tag
> > that
> > > works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was
> > something
> > > changed recently for passing a linux block device as "raw"?
> > >
> >
Setting sp_el2 causes trap while in EL3 (arm64 virt, cortex-a72)
Hello, experts,
When I run a bare-metal program on virt, cortex-a72 using command below,
(beginning of pflash.img containing .bin file objcopy'ed from .elf)
${QEMU_DIR}/qemu-system-aarch64 -machine type=virt,gic-version=3,secure=true
-cpu cortex-a72 -nographic -smp 1 -m 2048 -drive
if=pflash,file=pflash.img,format=raw,readonly=on -s -S
The "msr sp_el2, x0" instruction causes trap to addr 0x200(synch, from same
EL while using SP_Ex). I checked I was still in EL3 and the spsel reg was 1
just before the trap.
Below is the code with the trapped instruction marked.
// Zero the stack pointers, link registers and status registers
mov sp, x0
msr sp_el0, x0
msr sp_el1, x0
msr sp_el2, x0 <== trap
msr elr_el1, x0
msr elr_el2, x0
msr elr_el3, x0
msr spsr_el1, x0
msr spsr_el2, x0
msr spsr_el3, x0
Why does it cause trap when I set sp_el2 while in EL3? By the way, RTL
simulation for the chip (armv8.4 based) doesn't cause trap.
What difference can make this difference in trap behavior?
Thanks in advance.
Chan Kim
Re: Some more questions with regards to QEMU clock record and replay
Thank you Pavel. Your answers make the clock record-replay process much clearer to me now. Best Regards, Arnab On Tue, Mar 2, 2021 at 12:49 PM Pavel Dovgalyuk wrote: > On 01.03.2021 20:16, Arnabjyoti Kalita wrote: > > Hello all, > > > > I am really thankful for the wonderful answers in my last post linked > below- > > > > https://lists.nongnu.org/archive/html/qemu-discuss/2021-02/msg00131.html > > > > In continuation with the last post, I have a few more questions to ask - > > > > My experiment is still, mostly the same. I record clock values in KVM > > mode, and then replay the clock values in TCG mode. However, now I am > > recording and replaying all of the clock values (I was only > > recording/replaying the host clock previously). However, I do not use > > the -icount feature. > > > > - Why are clock values being replayed at checkpoints? > > Timers are replayed at checkpoints to be synchronized with vCPU. > Other clock requests (e.g., caused by vCPU instruction) are replayed > immediately. > > > - Can we ignore replaying at checkpoints and do a dumb replay as and > > when the clock read actually happens? > > I think we can, if we need just clock synchronization. > > > - Based on the documentation available, I can see that checkpoints are > > necessary for thread synchronization. Does this mean, if I do not replay > > clock values at checkpoints, the guest kernel scheduler might behave > > incorrectly during replay ? > > Checkpoints are related to QEMU threads, not guest threads. > Timers are needed for virtual devices, that can generate interrupts, DMA > requests and so on. Therefore we synchronize them with vCPU to make > execution deterministic. > > > Pavel Dovgalyuk >
Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0
When you say "instal", do you mean configuring another VM with the same SSD
in libvirt? I am not actually using the manually compiled version of qemu
with libvirt, I just grabbed the command line from it and adjusted it a bit
to work separately. And the libvirt that created it is fairly recent. I can
certainly change the machine type there if you tell me what you want
tested. This is my Windows to go image that I use in all kinds of places
and it should be able to boot in both UEFI and Bios modes.
On Wed, Mar 3, 2021 at 2:06 PM Michael S. Tsirkin wrote:
> OK great, good to know. note it works because you
> specified an old machine type as libvirt does for
> old installed VMs.
>
> My next question then is, what happens if you install
> a new VM? Does it work fine for you then?
>
>
> On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote:
> > This change works perfectly, thank you!
> >
> > On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin
> wrote:
> >
> > Can you try this please:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git
> tags/for_upstream
> >
> > ?
> >
> >
> > On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> > > I found the commit that breaks my VM. Anybody has any background
> on why
> > it was
> > > done? The comments are fairly extensive, but they are Mac related
> and I
> > am
> > > running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change
> > definitely
> > > breaks Windows 10. Anything before I can check out, compile and it
> runs
> > fine.
> > > Anything after this commit and it produces that boot device
> inaccessible
> > error.
> > > Reverting this change on the current master also makes it work
> fine.
> > >
> > > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> > > af1b80ae56c9495999e8ccf7b70ef894378de642
> > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > > index b7bc2a..7a5a8b3521 100644
> > > --- a/hw/i386/acpi-build.c
> > > +++ b/hw/i386/acpi-build.c
> > > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> > > dev = aml_device("PCI0");
> > > aml_append(dev, aml_name_decl("_HID",
> aml_eisaid("PNP0A03")));
> > > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > > -aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > > +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > > aml_append(sb_scope, dev);
> > > aml_append(dsdt, sb_scope);
> > >
> > > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> > > aml_append(dev, aml_name_decl("_HID",
> aml_eisaid("PNP0A08")));
> > > aml_append(dev, aml_name_decl("_CID",
> aml_eisaid("PNP0A03")));
> > > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > > -aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > > +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > > aml_append(dev, build_q35_osc_method());
> > > aml_append(sb_scope, dev);
> > > aml_append(dsdt, sb_scope);
> > >
> > > It looks like a regression issue in 5.2.x so I registered a bug for
> > it: https:/
> > > /bugs.launchpad.net/qemu/+bug/1917565
> > >
> > >
> > > On Sun, Feb 28, 2021 at 9:13 PM Nick S
> wrote:
> > >
> > >
> > > I have a VM set up on a USB SSD drive that I assign directly
> using
> > linux
> > > device (-blockdev
> '{"driver":"host_device","filename":"/dev/disk/
> > by-id/
> > >
> >
>
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> > >
> >
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> > >
> > > I've been using it for a few years now and recently decided to
> > compile the
> > > most recent version of qemu to do some hacking. To my
> surprise, when
> > I
> > > compiled the master branch, Windows failed to load with the
> "Boot
> > Device
> > > Inaccessible" error. I went through tags in git and the latest
> tag
> > that
> > > works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was
> > something
> > > changed recently for passing a linux block device as "raw"?
> > >
> > > Thank you,
> > > Nick
> > >
> >
> >
>
>
Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0
OK great, good to know. note it works because you
specified an old machine type as libvirt does for
old installed VMs.
My next question then is, what happens if you install
a new VM? Does it work fine for you then?
On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote:
> This change works perfectly, thank you!
>
> On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin wrote:
>
> Can you try this please:
>
> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> ?
>
>
> On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> > I found the commit that breaks my VM. Anybody has any background on why
> it was
> > done? The comments are fairly extensive, but they are Mac related and I
> am
> > running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change
> definitely
> > breaks Windows 10. Anything before I can check out, compile and it runs
> fine.
> > Anything after this commit and it produces that boot device inaccessible
> error.
> > Reverting this change on the current master also makes it work fine.
> >
> > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> > af1b80ae56c9495999e8ccf7b70ef894378de642
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index b7bc2a..7a5a8b3521 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > dev = aml_device("PCI0");
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
> > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
> > aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(dev, build_q35_osc_method());
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
> > It looks like a regression issue in 5.2.x so I registered a bug for
> it: https:/
> > /bugs.launchpad.net/qemu/+bug/1917565
> >
> >
> > On Sun, Feb 28, 2021 at 9:13 PM Nick S wrote:
> >
> >
> > I have a VM set up on a USB SSD drive that I assign directly using
> linux
> > device (-blockdev '{"driver":"host_device","filename":"/dev/disk/
> by-id/
> >
>
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> >
>
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> >
> > I've been using it for a few years now and recently decided to
> compile the
> > most recent version of qemu to do some hacking. To my surprise, when
> I
> > compiled the master branch, Windows failed to load with the "Boot
> Device
> > Inaccessible" error. I went through tags in git and the latest tag
> that
> > works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was
> something
> > changed recently for passing a linux block device as "raw"?
> >
> > Thank you,
> > Nick
> >
>
>
Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0
This change works perfectly, thank you!
On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin wrote:
> Can you try this please:
>
> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> ?
>
>
> On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> > I found the commit that breaks my VM. Anybody has any background on why
> it was
> > done? The comments are fairly extensive, but they are Mac related and I
> am
> > running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change
> definitely
> > breaks Windows 10. Anything before I can check out, compile and it runs
> fine.
> > Anything after this commit and it produces that boot device inaccessible
> error.
> > Reverting this change on the current master also makes it work fine.
> >
> > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> > af1b80ae56c9495999e8ccf7b70ef894378de642
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index b7bc2a..7a5a8b3521 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > dev = aml_device("PCI0");
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > -aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
> > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
> > aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > -aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(dev, build_q35_osc_method());
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
> > It looks like a regression issue in 5.2.x so I registered a bug for
> it: https:/
> > /bugs.launchpad.net/qemu/+bug/1917565
> >
> >
> > On Sun, Feb 28, 2021 at 9:13 PM Nick S wrote:
> >
> >
> > I have a VM set up on a USB SSD drive that I assign directly using
> linux
> > device (-blockdev
> '{"driver":"host_device","filename":"/dev/disk/by-id/
> >
>
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> >
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> >
> > I've been using it for a few years now and recently decided to
> compile the
> > most recent version of qemu to do some hacking. To my surprise, when
> I
> > compiled the master branch, Windows failed to load with the "Boot
> Device
> > Inaccessible" error. I went through tags in git and the latest tag
> that
> > works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was
> something
> > changed recently for passing a linux block device as "raw"?
> >
> > Thank you,
> > Nick
> >
>
>
Qemu: New Machine and Device
Hi All,
Apologies in advance for long post.
I am new to qemu, I am trying to add a machine in qemu. To add the machine i
have used following code,
#define TYPE_DRA7X_MACHINE MACHINE_TYPE_NAME("dra7x")
void dra7xSoC_init(MachineState *machine) {
int sram_size;
int flash_size;
DeviceState *nvic;
dra7x_periph_t periph;
flash_size = 16 * 1024;
sram_size = 32 * 1024;
MemoryRegion *sram = g_new(MemoryRegion, 1);
MemoryRegion *flash = g_new(MemoryRegion, 1);
MemoryRegion *system_memory = get_system_memory();
memory_region_init_ram(flash, NULL, "dra7x.flash", flash_size, _fatal);
memory_region_add_subregion(system_memory, 0, flash);
memory_region_init_ram(sram, NULL, "dra7x.sram", sram_size, _fatal);
memory_region_add_subregion(system_memory, 0x2000, sram);
nvic = qdev_create(NULL, TYPE_ARMV7M);
printf("dra7xSoC_init(): done armv7m_instance_init \n");
qdev_prop_set_uint32(nvic, "num-irq", 0);
qdev_prop_set_string(nvic, "cpu-type", machine->cpu_type);
qdev_prop_set_bit(nvic, "enable-bitband", true);
object_property_set_link(OBJECT(nvic), OBJECT(get_system_memory()), "memory",
_abort);
object_property_set_bool(OBJECT(nvic), true, "realized", _fatal);
armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename, flash_size);
}
static void dra7x_machine_class_init(ObjectClass *oc, void *data) {
MachineClass *mc = MACHINE_CLASS(oc);
mc->desc = "dra7x";
mc->init = dra7x_init;
mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
}
static const TypeInfo dra7x_info = {
.name = TYPE_DRA7X_MACHINE,
.parent= TYPE_MACHINE,
.class_init= dra7x_machine_class_init,
};
static void dra7x_register_types(void)
{
type_register_static(_info);
}
type_init(dra7x_register_types)
Now I want to add few peripheral to the machine and mapped range of guest
memory that is implemented by host callbacks; each read or write causes a
callback to be called on the host.
# to add the device
DeviceState *control_module_core_dev = qdev_create(NULL,
"dra7x-control-module-core");
SysBusDevice *s;
s = SYS_BUS_DEVICE(control_module_core_dev);
qdev_init_nofail(control_module_core_dev);
sysbus_mmio_map(s, 0, 0X4a002000);
//periph = DRA7X_L4PER_PRM;
DeviceState *l4per_prm_dev = qdev_create(NULL, "dra7x-l4per-prm");
SysBusDevice *s1;
s1 = SYS_BUS_DEVICE(l4per_prm_dev);
qdev_init_nofail(l4per_prm_dev);
sysbus_mmio_map(s1, 0, 0X4ae07400);
# to initialize memory region and register callbacks
static const MemoryRegionOps dra7x_control_module_core_ops = {
.read = dra7x_control_module_core_read,
.write = dra7x_control_module_core_write,
.valid.min_access_size = 2,
.valid.max_access_size = 4,
.endianness = DEVICE_NATIVE_ENDIAN
};
memory_region_init_io(>iomem, obj, _control_module_core_ops,
s,"control_module_core", 0x2000);
sysbus_init_mmio(SYS_BUS_DEVICE(obj), >iomem);
Upon writing/reading on the mapped address read/write callback is not getting
called.
Requesting expert to advise how to make it work.
Thanks,
Rahul
This message contains information that may be privileged or confidential and is
the property of the KPIT Technologies Ltd. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain copy, disseminate, distribute, or use this
message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message. KPIT
Technologies Ltd. does not accept any liability for virus infected mails.
Re: How to start an armv8 machine in EL3?
c...@etri.re.kr writes:
> Found out how to do it! (I needed secure=true).
Hmm I would hope true and on are synonyms... might have to poke that. I
forgot about the gic-version, we should make that easier to get right.
> ${QEMU_DIR}/qemu-system-aarch64 -machine type=virt,gic-version=3,secure=true
> -cpu cortex-a72 -nographic -smp 1 -m 2048 -drive
> if=pflash,file=pflash.img,format=raw,readonly=on -s -S
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg06622.html
> Thanks!
> Chan Kim
>
>> -Original Message-
>> From: c...@etri.re.kr
>> Sent: Wednesday, March 3, 2021 11:04 PM
>> To: 'Alex Bennée'
>> Cc: 'qemu-discuss@nongnu.org'
>> Subject: RE: How to start an armv8 machine in EL3?
>>
>> Hi Alex Bennée,
>>
>> Sorry, machine ab21q is just the copy of machine virt.
>> I found the pflash.img contained all zero in the beginning so it cause
>> invalid instruction trap.
>> (thanks for the -d int,exec,in_asm option, I have to first learn more
>> about the qemu usage than the internal.) So I did 'cp test.bin pflash.img;
>> truncate -s 67108864 pflash.img' to cut it to 64MB.
>> (The test.bin was almost 67MB, I was confused by the small sized test.elf
>> which was only 776KB).
>> Now with the ' ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -
>> nographic -smp 1 -m 2048 -drive
>> if=pflash,file=pflash.img,format=raw,readonly=on -s -S' command, And after
>> attaching gdb, I can see the original assembly code is being executed.
>> But with this method, it still is in EL1 (I can see with 'mrs x8,
>> currentel' shortly after the start), And the 'msr sp_el1, x0' instruction
>> causes trap to 0x200.
>> Could you give me more advice on this?
>> Thank you very much.
>>
>> Chan Kim
>>
>> > -Original Message-
>> > From: Alex Bennée
>> > Sent: Wednesday, March 3, 2021 9:01 PM
>> > To: c...@etri.re.kr
>> > Cc: qemu-discuss@nongnu.org
>> > Subject: Re: How to start an armv8 machine in EL3?
>> >
>> >
>> > c...@etri.re.kr writes:
>> >
>> > > Hello Alex Bennée,
>> > >
>> > > Thank you for the help!
>> > > I didn't know "-kernel xxx.elf" method makes it start at EL1 by the
>> > > loader stub, and doing "--machine virtualization=on" makes it start
>> > > at
>> > EL2. I checked these using gdb.
>> > >
>> > > And then I tested your suggestion :
>> > > ${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic
>> > > -smp 1 -m 2048 -drive
>> > > if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on -s
>> > > -S
>> >
>> > Hold on you've just switched from -M virt to -M ab21q? I don't even
>> > recognise that model.
>> >
>> > > And it gave me :
>> > > qemu-system-aarch64: device requires 67108864 bytes, block backend
>> > > provides 776704 bytes
>> > >
>> > > Looks like the pflash device size is 64MB and my .bin file (which I
>> > > made
>> > with objcopy from .elf file) is not big enough to fill the device.
>> > > I made the .bin file inside the pflash.img file by doing
>> > > (https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
>> > >
>> > > cp ${KER_DIR}/ab21s_test.bin pflash.img
>> > > dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
>> > >
>> > > and tried
>> > > ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic
>> > > -smp 1 -m 2048 -drive
>> > > if=pflash,file=pflash.img,format=raw,readonly=on -
>> > s -S To see how the code works, but it traps from the first instruction.
>> >
>> > Is it the instruction you expect? Try single stepping with gdbstub
>> > while using -d int,exec,in_asm on your command line for more details.
>> >
>> > >
>> > > Can you tell me what's wrong with my command? (BTW I made .bin file
>> > > by aarch64-elf-objcopy -O binary test.elf test.bin )
>> > >
>> > > Again thanks for the kind explanation!
>> > > Best regards,
>> > >
>> > > Chan Kim
>> > >
>> > >> -Original Message-
>> > >> From: Alex Bennée
>> > >> Sent: Wednesday, March 3, 2021 7:05 PM
>> > >> To: c...@etri.re.kr
>> > >> Cc: qemu-discuss@nongnu.org
>> > >> Subject: Re: How to start an armv8 machine in EL3?
>> > >>
>> > >>
>> > >> c...@etri.re.kr writes:
>> > >>
>> > >> > Hello all,
>> > >> >
>> > >> > I found out in a baremetal program I run for qemu aarch64 'virt'
>> > >> > machine (cpu is cortex-a72),
>> > >> >
>> > >> > the "msr sp_el1, x0" instruction causes trap making PC jump to
>> > >> > 0x200 which is the vector address for synchronous exception, from
>> > >> > current EL while using SP_ELx (if the vector base address was 0,
>> > which is the case).
>> > >> >
>> > >> > (Ref :
>> > >> > https://developer.arm.com/documentation/102412/0100/The-vector-ta
>> > >> > bl
>> > >> > es
>> > >> > )
>> > >> >
>> > >> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4'
>> > >> > so it is
>> > >> > EL1
>> > >> > (https://community.arm.com/developer/ip-products/processors/f/cor
>> > >> > te
>> > >> > x-a
>> > >> > -forum
>> > >> > /10303/armv8-a-currentel-register-definition)
>> > >> >
>> > >> > How come cortex-a72
Re: How to start an armv8 machine in EL3?
c...@etri.re.kr writes:
> Hi Alex Bennée,
>
> Sorry, machine ab21q is just the copy of machine virt.
> I found the pflash.img contained all zero in the beginning so it cause
> invalid instruction trap.
> (thanks for the -d int,exec,in_asm option, I have to first learn more
> about the qemu usage than the internal.)
You can see the cpu state with -d cpu so I can see on my system it's
reported as:
PSTATE=43cd -Z-- EL3h
> So I did 'cp test.bin pflash.img; truncate -s 67108864 pflash.img' to cut it
> to 64MB.
> (The test.bin was almost 67MB, I was confused by the small sized test.elf
> which was only 776KB).
> Now with the ' ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72
> -nographic -smp 1
> -m 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -s -S'
> command,
> And after attaching gdb, I can see the original assembly code is being
> executed.
> But with this method, it still is in EL1 (I can see with 'mrs x8,
> currentel' shortly after the start),
Can you confirm it disagrees with the state -d cpu reports?
> And the 'msr sp_el1, x0' instruction causes trap to 0x200.
> Could you give me more advice on this?
> Thank you very much.
>
> Chan Kim
>
>> -Original Message-
>> From: Alex Bennée
>> Sent: Wednesday, March 3, 2021 9:01 PM
>> To: c...@etri.re.kr
>> Cc: qemu-discuss@nongnu.org
>> Subject: Re: How to start an armv8 machine in EL3?
>>
>>
>> c...@etri.re.kr writes:
>>
>> > Hello Alex Bennée,
>> >
>> > Thank you for the help!
>> > I didn't know "-kernel xxx.elf" method makes it start at EL1 by the
>> > loader stub, and doing "--machine virtualization=on" makes it start at
>> EL2. I checked these using gdb.
>> >
>> > And then I tested your suggestion :
>> > ${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic
>> > -smp 1 -m 2048 -drive
>> > if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on -s -S
>>
>> Hold on you've just switched from -M virt to -M ab21q? I don't even
>> recognise that model.
>>
>> > And it gave me :
>> > qemu-system-aarch64: device requires 67108864 bytes, block backend
>> > provides 776704 bytes
>> >
>> > Looks like the pflash device size is 64MB and my .bin file (which I made
>> with objcopy from .elf file) is not big enough to fill the device.
>> > I made the .bin file inside the pflash.img file by doing
>> > (https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
>> >
>> > cp ${KER_DIR}/ab21s_test.bin pflash.img
>> > dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
>> >
>> > and tried
>> > ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic
>> > -smp 1 -m 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -
>> s -S To see how the code works, but it traps from the first instruction.
>>
>> Is it the instruction you expect? Try single stepping with gdbstub while
>> using -d int,exec,in_asm on your command line for more details.
>>
>> >
>> > Can you tell me what's wrong with my command? (BTW I made .bin file by
>> > aarch64-elf-objcopy -O binary test.elf test.bin )
>> >
>> > Again thanks for the kind explanation!
>> > Best regards,
>> >
>> > Chan Kim
>> >
>> >> -Original Message-
>> >> From: Alex Bennée
>> >> Sent: Wednesday, March 3, 2021 7:05 PM
>> >> To: c...@etri.re.kr
>> >> Cc: qemu-discuss@nongnu.org
>> >> Subject: Re: How to start an armv8 machine in EL3?
>> >>
>> >>
>> >> c...@etri.re.kr writes:
>> >>
>> >> > Hello all,
>> >> >
>> >> > I found out in a baremetal program I run for qemu aarch64 'virt'
>> >> > machine (cpu is cortex-a72),
>> >> >
>> >> > the "msr sp_el1, x0" instruction causes trap making PC jump to
>> >> > 0x200 which is the vector address for synchronous exception, from
>> >> > current EL while using SP_ELx (if the vector base address was 0,
>> which is the case).
>> >> >
>> >> > (Ref :
>> >> > https://developer.arm.com/documentation/102412/0100/The-vector-tabl
>> >> > es
>> >> > )
>> >> >
>> >> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4'
>> >> > so it is
>> >> > EL1
>> >> > (https://community.arm.com/developer/ip-products/processors/f/corte
>> >> > x-a
>> >> > -forum
>> >> > /10303/armv8-a-currentel-register-definition)
>> >> >
>> >> > How come cortex-a72 machines started at EL1?
>> >>
>> >> Are you booting a kernel directly? In this case the kernel will boot
>> >> into
>> >> EL1 unless you specify -machine type=virt,virtualization=on in which
>> >> case it will boot into EL2 and allow the kernel to utilise the
>> >> virtualisation extensions.
>> >>
>> >> > And if I want to make the virtual machine start at EL3 (this
>> >> > baremetal code assumes it should be in EL3 after reset, and it runs
>> >> > ok in rtl sim.), what should I do?
>> >>
>> >> Generally as only firmware deals with EL3 you would have it running
>> >> on some sort of flash device which the model would boot to directly
>> >> in EL3 rather than running the stub loader we have for the kernel.
>> >> For example to load the EDK
RE: How to start an armv8 machine in EL3?
Found out how to do it! (I needed secure=true).
${QEMU_DIR}/qemu-system-aarch64 -machine type=virt,gic-version=3,secure=true
-cpu cortex-a72 -nographic -smp 1 -m 2048 -drive
if=pflash,file=pflash.img,format=raw,readonly=on -s -S
https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg06622.html
Thanks!
Chan Kim
> -Original Message-
> From: c...@etri.re.kr
> Sent: Wednesday, March 3, 2021 11:04 PM
> To: 'Alex Bennée'
> Cc: 'qemu-discuss@nongnu.org'
> Subject: RE: How to start an armv8 machine in EL3?
>
> Hi Alex Bennée,
>
> Sorry, machine ab21q is just the copy of machine virt.
> I found the pflash.img contained all zero in the beginning so it cause
> invalid instruction trap.
> (thanks for the -d int,exec,in_asm option, I have to first learn more
> about the qemu usage than the internal.) So I did 'cp test.bin pflash.img;
> truncate -s 67108864 pflash.img' to cut it to 64MB.
> (The test.bin was almost 67MB, I was confused by the small sized test.elf
> which was only 776KB).
> Now with the ' ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -
> nographic -smp 1 -m 2048 -drive
> if=pflash,file=pflash.img,format=raw,readonly=on -s -S' command, And after
> attaching gdb, I can see the original assembly code is being executed.
> But with this method, it still is in EL1 (I can see with 'mrs x8,
> currentel' shortly after the start), And the 'msr sp_el1, x0' instruction
> causes trap to 0x200.
> Could you give me more advice on this?
> Thank you very much.
>
> Chan Kim
>
> > -Original Message-
> > From: Alex Bennée
> > Sent: Wednesday, March 3, 2021 9:01 PM
> > To: c...@etri.re.kr
> > Cc: qemu-discuss@nongnu.org
> > Subject: Re: How to start an armv8 machine in EL3?
> >
> >
> > c...@etri.re.kr writes:
> >
> > > Hello Alex Bennée,
> > >
> > > Thank you for the help!
> > > I didn't know "-kernel xxx.elf" method makes it start at EL1 by the
> > > loader stub, and doing "--machine virtualization=on" makes it start
> > > at
> > EL2. I checked these using gdb.
> > >
> > > And then I tested your suggestion :
> > > ${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic
> > > -smp 1 -m 2048 -drive
> > > if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on -s
> > > -S
> >
> > Hold on you've just switched from -M virt to -M ab21q? I don't even
> > recognise that model.
> >
> > > And it gave me :
> > > qemu-system-aarch64: device requires 67108864 bytes, block backend
> > > provides 776704 bytes
> > >
> > > Looks like the pflash device size is 64MB and my .bin file (which I
> > > made
> > with objcopy from .elf file) is not big enough to fill the device.
> > > I made the .bin file inside the pflash.img file by doing
> > > (https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
> > >
> > > cp ${KER_DIR}/ab21s_test.bin pflash.img
> > > dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
> > >
> > > and tried
> > > ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic
> > > -smp 1 -m 2048 -drive
> > > if=pflash,file=pflash.img,format=raw,readonly=on -
> > s -S To see how the code works, but it traps from the first instruction.
> >
> > Is it the instruction you expect? Try single stepping with gdbstub
> > while using -d int,exec,in_asm on your command line for more details.
> >
> > >
> > > Can you tell me what's wrong with my command? (BTW I made .bin file
> > > by aarch64-elf-objcopy -O binary test.elf test.bin )
> > >
> > > Again thanks for the kind explanation!
> > > Best regards,
> > >
> > > Chan Kim
> > >
> > >> -Original Message-
> > >> From: Alex Bennée
> > >> Sent: Wednesday, March 3, 2021 7:05 PM
> > >> To: c...@etri.re.kr
> > >> Cc: qemu-discuss@nongnu.org
> > >> Subject: Re: How to start an armv8 machine in EL3?
> > >>
> > >>
> > >> c...@etri.re.kr writes:
> > >>
> > >> > Hello all,
> > >> >
> > >> > I found out in a baremetal program I run for qemu aarch64 'virt'
> > >> > machine (cpu is cortex-a72),
> > >> >
> > >> > the "msr sp_el1, x0" instruction causes trap making PC jump to
> > >> > 0x200 which is the vector address for synchronous exception, from
> > >> > current EL while using SP_ELx (if the vector base address was 0,
> > which is the case).
> > >> >
> > >> > (Ref :
> > >> > https://developer.arm.com/documentation/102412/0100/The-vector-ta
> > >> > bl
> > >> > es
> > >> > )
> > >> >
> > >> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4'
> > >> > so it is
> > >> > EL1
> > >> > (https://community.arm.com/developer/ip-products/processors/f/cor
> > >> > te
> > >> > x-a
> > >> > -forum
> > >> > /10303/armv8-a-currentel-register-definition)
> > >> >
> > >> > How come cortex-a72 machines started at EL1?
> > >>
> > >> Are you booting a kernel directly? In this case the kernel will
> > >> boot into
> > >> EL1 unless you specify -machine type=virt,virtualization=on in
> > >> which case it will boot into EL2 and allow the kernel to utilise
> > >> the virtualisation extensions.
> > >>
> > >> >
RE: How to start an armv8 machine in EL3?
Hi Alex Bennée,
Sorry, machine ab21q is just the copy of machine virt.
I found the pflash.img contained all zero in the beginning so it cause invalid
instruction trap.
(thanks for the -d int,exec,in_asm option, I have to first learn more about the
qemu usage than the internal.)
So I did 'cp test.bin pflash.img; truncate -s 67108864 pflash.img' to cut it to
64MB.
(The test.bin was almost 67MB, I was confused by the small sized test.elf which
was only 776KB).
Now with the ' ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72
-nographic -smp 1
-m 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -s -S' command,
And after attaching gdb, I can see the original assembly code is being executed.
But with this method, it still is in EL1 (I can see with 'mrs x8, currentel'
shortly after the start),
And the 'msr sp_el1, x0' instruction causes trap to 0x200.
Could you give me more advice on this?
Thank you very much.
Chan Kim
> -Original Message-
> From: Alex Bennée
> Sent: Wednesday, March 3, 2021 9:01 PM
> To: c...@etri.re.kr
> Cc: qemu-discuss@nongnu.org
> Subject: Re: How to start an armv8 machine in EL3?
>
>
> c...@etri.re.kr writes:
>
> > Hello Alex Bennée,
> >
> > Thank you for the help!
> > I didn't know "-kernel xxx.elf" method makes it start at EL1 by the
> > loader stub, and doing "--machine virtualization=on" makes it start at
> EL2. I checked these using gdb.
> >
> > And then I tested your suggestion :
> > ${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic
> > -smp 1 -m 2048 -drive
> > if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on -s -S
>
> Hold on you've just switched from -M virt to -M ab21q? I don't even
> recognise that model.
>
> > And it gave me :
> > qemu-system-aarch64: device requires 67108864 bytes, block backend
> > provides 776704 bytes
> >
> > Looks like the pflash device size is 64MB and my .bin file (which I made
> with objcopy from .elf file) is not big enough to fill the device.
> > I made the .bin file inside the pflash.img file by doing
> > (https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
> >
> > cp ${KER_DIR}/ab21s_test.bin pflash.img
> > dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
> >
> > and tried
> > ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic
> > -smp 1 -m 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -
> s -S To see how the code works, but it traps from the first instruction.
>
> Is it the instruction you expect? Try single stepping with gdbstub while
> using -d int,exec,in_asm on your command line for more details.
>
> >
> > Can you tell me what's wrong with my command? (BTW I made .bin file by
> > aarch64-elf-objcopy -O binary test.elf test.bin )
> >
> > Again thanks for the kind explanation!
> > Best regards,
> >
> > Chan Kim
> >
> >> -Original Message-
> >> From: Alex Bennée
> >> Sent: Wednesday, March 3, 2021 7:05 PM
> >> To: c...@etri.re.kr
> >> Cc: qemu-discuss@nongnu.org
> >> Subject: Re: How to start an armv8 machine in EL3?
> >>
> >>
> >> c...@etri.re.kr writes:
> >>
> >> > Hello all,
> >> >
> >> > I found out in a baremetal program I run for qemu aarch64 'virt'
> >> > machine (cpu is cortex-a72),
> >> >
> >> > the "msr sp_el1, x0" instruction causes trap making PC jump to
> >> > 0x200 which is the vector address for synchronous exception, from
> >> > current EL while using SP_ELx (if the vector base address was 0,
> which is the case).
> >> >
> >> > (Ref :
> >> > https://developer.arm.com/documentation/102412/0100/The-vector-tabl
> >> > es
> >> > )
> >> >
> >> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4'
> >> > so it is
> >> > EL1
> >> > (https://community.arm.com/developer/ip-products/processors/f/corte
> >> > x-a
> >> > -forum
> >> > /10303/armv8-a-currentel-register-definition)
> >> >
> >> > How come cortex-a72 machines started at EL1?
> >>
> >> Are you booting a kernel directly? In this case the kernel will boot
> >> into
> >> EL1 unless you specify -machine type=virt,virtualization=on in which
> >> case it will boot into EL2 and allow the kernel to utilise the
> >> virtualisation extensions.
> >>
> >> > And if I want to make the virtual machine start at EL3 (this
> >> > baremetal code assumes it should be in EL3 after reset, and it runs
> >> > ok in rtl sim.), what should I do?
> >>
> >> Generally as only firmware deals with EL3 you would have it running
> >> on some sort of flash device which the model would boot to directly
> >> in EL3 rather than running the stub loader we have for the kernel.
> >> For example to load the EDK firmware you would have:
> >>
> >>-drive
> >> if=pflash,file=/usr/share/AAVMF/AAVMF_CODE.fd,format=raw,readonly=on \
> >>-drive
> >> if=pflash,file=/home/alex/models/qemu-arm64-efivars,format=raw
> >>
> >> as part of your command line. You also need to enable secure mode in
> >> the machine options (-machine type=virt,secure=on).
> >>
> >> >
>
I got LAN-peer Qemu VM working
Hi all, I got LAN-peer VM working. So my VM guest looks like just another metal computer. Once I figured it out, and it took me a lot of time, it was pretty simple. I documented it here: http://troubleshooters.com/linux/qemu/nobs.htm SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: How to start an armv8 machine in EL3?
c...@etri.re.kr writes:
> Hello Alex Bennée,
>
> Thank you for the help!
> I didn't know "-kernel xxx.elf" method makes it start at EL1 by the loader
> stub,
> and doing "--machine virtualization=on" makes it start at EL2. I checked
> these using gdb.
>
> And then I tested your suggestion :
> ${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic -smp 1 -m
> 2048 -drive if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on
> -s -S
Hold on you've just switched from -M virt to -M ab21q? I don't even
recognise that model.
> And it gave me :
> qemu-system-aarch64: device requires 67108864 bytes, block backend provides
> 776704 bytes
>
> Looks like the pflash device size is 64MB and my .bin file (which I made with
> objcopy from .elf file) is not big enough to fill the device.
> I made the .bin file inside the pflash.img file by doing
> (https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
>
> cp ${KER_DIR}/ab21s_test.bin pflash.img
> dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
>
> and tried
> ${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic -smp 1 -m
> 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -s -S
> To see how the code works, but it traps from the first instruction.
Is it the instruction you expect? Try single stepping with gdbstub while
using -d int,exec,in_asm on your command line for more details.
>
> Can you tell me what's wrong with my command? (BTW I made .bin file by
> aarch64-elf-objcopy -O binary test.elf test.bin )
>
> Again thanks for the kind explanation!
> Best regards,
>
> Chan Kim
>
>> -Original Message-
>> From: Alex Bennée
>> Sent: Wednesday, March 3, 2021 7:05 PM
>> To: c...@etri.re.kr
>> Cc: qemu-discuss@nongnu.org
>> Subject: Re: How to start an armv8 machine in EL3?
>>
>>
>> c...@etri.re.kr writes:
>>
>> > Hello all,
>> >
>> > I found out in a baremetal program I run for qemu aarch64 'virt'
>> > machine (cpu is cortex-a72),
>> >
>> > the "msr sp_el1, x0" instruction causes trap making PC jump to 0x200
>> > which is the vector address for synchronous exception, from current EL
>> > while using SP_ELx (if the vector base address was 0, which is the case).
>> >
>> > (Ref :
>> > https://developer.arm.com/documentation/102412/0100/The-vector-tables
>> > )
>> >
>> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4' so
>> > it is
>> > EL1
>> > (https://community.arm.com/developer/ip-products/processors/f/cortex-a
>> > -forum
>> > /10303/armv8-a-currentel-register-definition)
>> >
>> > How come cortex-a72 machines started at EL1?
>>
>> Are you booting a kernel directly? In this case the kernel will boot into
>> EL1 unless you specify -machine type=virt,virtualization=on in which case
>> it will boot into EL2 and allow the kernel to utilise the virtualisation
>> extensions.
>>
>> > And if I want to make the virtual machine start at EL3 (this baremetal
>> > code assumes it should be in EL3 after reset, and it runs ok in rtl
>> > sim.), what should I do?
>>
>> Generally as only firmware deals with EL3 you would have it running on
>> some sort of flash device which the model would boot to directly in EL3
>> rather than running the stub loader we have for the kernel. For example to
>> load the EDK firmware you would have:
>>
>>-drive
>> if=pflash,file=/usr/share/AAVMF/AAVMF_CODE.fd,format=raw,readonly=on \
>>-drive if=pflash,file=/home/alex/models/qemu-arm64-efivars,format=raw
>>
>> as part of your command line. You also need to enable secure mode in the
>> machine options (-machine type=virt,secure=on).
>>
>> >
>> > Thank you very much for reading.
>> >
>> > Chan Kim
>> >
>> >
>>
>>
>> --
>> Alex Bennée
--
Alex Bennée
RE: How to start an armv8 machine in EL3?
Hello Alex Bennée,
Thank you for the help!
I didn't know "-kernel xxx.elf" method makes it start at EL1 by the loader stub,
and doing "--machine virtualization=on" makes it start at EL2. I checked these
using gdb.
And then I tested your suggestion :
${QEMU_DIR}/qemu-system-aarch64 -M ab21q -cpu cortex-a72 -nographic -smp 1 -m
2048 -drive if=pflash,file=${KER_DIR}/ab21s_test.bin,format=raw,readonly=on -s
-S
And it gave me :
qemu-system-aarch64: device requires 67108864 bytes, block backend provides
776704 bytes
Looks like the pflash device size is 64MB and my .bin file (which I made with
objcopy from .elf file) is not big enough to fill the device.
I made the .bin file inside the pflash.img file by doing
(https://xnand.netlify.app/2019/10/03/armv8-qemu-efi-aarch64.html )
cp ${KER_DIR}/ab21s_test.bin pflash.img
dd if=/dev/zero of=pflash.img bs=1c count=1 seek=67108863
and tried
${QEMU_DIR}/qemu-system-aarch64 -M virt -cpu cortex-a72 -nographic -smp 1 -m
2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -s -S
To see how the code works, but it traps from the first instruction.
Can you tell me what's wrong with my command? (BTW I made .bin file by
aarch64-elf-objcopy -O binary test.elf test.bin )
Again thanks for the kind explanation!
Best regards,
Chan Kim
> -Original Message-
> From: Alex Bennée
> Sent: Wednesday, March 3, 2021 7:05 PM
> To: c...@etri.re.kr
> Cc: qemu-discuss@nongnu.org
> Subject: Re: How to start an armv8 machine in EL3?
>
>
> c...@etri.re.kr writes:
>
> > Hello all,
> >
> > I found out in a baremetal program I run for qemu aarch64 'virt'
> > machine (cpu is cortex-a72),
> >
> > the "msr sp_el1, x0" instruction causes trap making PC jump to 0x200
> > which is the vector address for synchronous exception, from current EL
> > while using SP_ELx (if the vector base address was 0, which is the case).
> >
> > (Ref :
> > https://developer.arm.com/documentation/102412/0100/The-vector-tables
> > )
> >
> > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4' so
> > it is
> > EL1
> > (https://community.arm.com/developer/ip-products/processors/f/cortex-a
> > -forum
> > /10303/armv8-a-currentel-register-definition)
> >
> > How come cortex-a72 machines started at EL1?
>
> Are you booting a kernel directly? In this case the kernel will boot into
> EL1 unless you specify -machine type=virt,virtualization=on in which case
> it will boot into EL2 and allow the kernel to utilise the virtualisation
> extensions.
>
> > And if I want to make the virtual machine start at EL3 (this baremetal
> > code assumes it should be in EL3 after reset, and it runs ok in rtl
> > sim.), what should I do?
>
> Generally as only firmware deals with EL3 you would have it running on
> some sort of flash device which the model would boot to directly in EL3
> rather than running the stub loader we have for the kernel. For example to
> load the EDK firmware you would have:
>
>-drive
> if=pflash,file=/usr/share/AAVMF/AAVMF_CODE.fd,format=raw,readonly=on \
>-drive if=pflash,file=/home/alex/models/qemu-arm64-efivars,format=raw
>
> as part of your command line. You also need to enable secure mode in the
> machine options (-machine type=virt,secure=on).
>
> >
> > Thank you very much for reading.
> >
> > Chan Kim
> >
> >
>
>
> --
> Alex Bennée
Re: How to start an armv8 machine in EL3?
c...@etri.re.kr writes: > Hello all, > > I found out in a baremetal program I run for qemu aarch64 'virt' machine > (cpu is cortex-a72), > > the "msr sp_el1, x0" instruction causes trap making PC jump to 0x200 which > is the vector address for synchronous exception, from current EL while using > SP_ELx (if the vector base address was 0, which is the case). > > (Ref : https://developer.arm.com/documentation/102412/0100/The-vector-tables > ) > > When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4' so it is > EL1 > (https://community.arm.com/developer/ip-products/processors/f/cortex-a-forum > /10303/armv8-a-currentel-register-definition) > > How come cortex-a72 machines started at EL1? Are you booting a kernel directly? In this case the kernel will boot into EL1 unless you specify -machine type=virt,virtualization=on in which case it will boot into EL2 and allow the kernel to utilise the virtualisation extensions. > And if I want to make the virtual machine start at EL3 (this baremetal code > assumes it should be in EL3 after reset, and it runs ok in rtl sim.), what > should I do? Generally as only firmware deals with EL3 you would have it running on some sort of flash device which the model would boot to directly in EL3 rather than running the stub loader we have for the kernel. For example to load the EDK firmware you would have: -drive if=pflash,file=/usr/share/AAVMF/AAVMF_CODE.fd,format=raw,readonly=on \ -drive if=pflash,file=/home/alex/models/qemu-arm64-efivars,format=raw as part of your command line. You also need to enable secure mode in the machine options (-machine type=virt,secure=on). > > Thank you very much for reading. > > Chan Kim > > -- Alex Bennée
Re: Is ARM Cortex-A55 CPU supported on QEMU on some branch?
shengjian.xu writes: > Hi, > > I found that A55 is not in the “struct ARMCPUInfo aarch64_cpus” of > QEMU5.2. Not currently. The closest you can get currently is using -cpu max which will bring in all the ARMv8.x features currently implemented in QEMU. It there any particular architectural feature you are interested in or is it the complete model that is of interest? > Is there somebody made A55 supported on QEMU? We hope to implement a Cortex-A76 model in the next development cycle (hopefully for QEMU 6.1). The biggest chunk of work is implementing the GICv4 and GIC ITS emulation. From there on the aim is to add models for Neoverse N1/V1 in future releases. If you want to help with test and review I can ask the various authors to Cc you on patch sets. -- Alex Bennée
Re: How to make a VM guest look like just another metal machine on my LAN?
Alok Prasad writes:
> Just a simple Bridge configuration is too daunting to configure with QMEU.
> serious some helper script /config is need to make this simpler for user of
> qemu to use this.
Generally we advise using a higher layer VM manager based on libvirt to
do these sorts of things. They make the process of configuring networks
a lot easier than doing it all by hand.
>
> On Sun, Feb 21, 2021 at 2:16 PM Steve Litt
> wrote:
>
>> Hi all,
>>
>> My LAN at home is on 192.168.0.0/24, connected to the Internet via a
>> cablemodem/firewall/router/gateway at 192.168.0.1. My Daily Driver
>> Desktop (DDD), which will after this be referred to as the "host" or
>> "metal host" is at 192.168.0.2. I have a printer with an http interface
>> at 192.168.0.13. Throughout this post I'm careful to discriminate
>> between the metal host and the VM guest, which is created on the metal
>> host, for all config options.
>>
>> What I'm trying to accomplish is to launch a VM guest (Devuan) on my
>> metal host (Void Linux), such that the VM guest performs as if it were
>> just another physical computer on my LAN.
>>
>> I've been reading and experimenting for four days and still don't have
>> what I need. Here are some of the documents I've used trying to get
>> this done:
>>
>> https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
>>
>>
>> https://ahelpme.com/linux/howto-do-qemu-full-virtualization-with-bridged-networking/
>>
>> http://www.mpaoli.net/~root/bin/TEMPLATE
>>
>>
>> https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network
>>
>> I'm trying to do it purely with ip commands, although I could use brctl
>> if necessary. I'm staying away from virt-manager and aqemu because they
>> don't work on my Void Linux metal host, and would just add even more
>> variables and ambiguity.
>>
>> Speaking of ambiguity, every document I've read (and I've read dozens)
>> has the following ambiguities:
>>
>> 1) When discussing a setting, they don't indicate whether that setting
>>should be on the metal host or the VM guest. Perhaps to a person who
>>thoroughly understands virtual machines, such a distinction would be
>>obvious via context, but it's not obvious to me.
>>
>> 2) When specifying an "id=whatever", they don't indicate how the id
>>would be used, or what other references to that id need to be made.
>>
>> 3) They include no realistic steps for troubleshooting a "warning:
>>netdev mybridge0 has no peer" type warning, nor even explain what it
>>means more than a few guesses and "have you tried...".
>>
>> Based on the previously listed links, I deduce that the TAP is created
>> by the guest VM, in such a way that it attaches to the bridge created on
>> the metal host, and therefore I have no need to create a TAP on the
>> metal host.
>>
>> Here's my progress so far, based on the links listed above and my
>> other readings and experimentation:
>>
>> ***
>>
>> I build the bridge purely with ip commands. Also, I don't mess
>> with the firewall (which perhaps has been my problem all along). I'll
>> investigate the firewall aspect tomorrow.
>>
>> Below are some scripts and stuff I'm using. The following is
>> upnet.sh, which I use to set up networking on the metal host, which
>> happens to run Void Linux, which has no /etc/network/interfaces:
>>
>> =
>> #!/bin/sh
>>
>> use_bridge=1
>> use_tap=0
>>
>> dev="enp40s0"
>> ipaddr_major="192.168.0.2"
>> ipaddr_minor="192.168.0.102"
>> gateway="192.168.0.1"
>>
>> error_tap_without_bridge(){
>>echo -n "ERROR: Can\'t set TAP without "
>>echo -n "BRIDGE! "
>>echo Aborting...
>>exit 1
>> }
>>
>>
>> enable_ip_forwarding(){
>>echo 1 > /proc/sys/net/ipv4/ip_forward
>> }
>>
>> unset_everything(){
>>dev=$1
>>ip_maj=$2
>>ip_min=$3
>>gateway=$4
>>echo "Unsetting everything for $dev, $ip_maj and $ip_min"
>>ip link set dev tap0 down
>>brctl delif br0 tap0
>>ip link del tap0
>>ip link set dev br0 down
>>ip addr del $ip_min/24 dev br0
>>ip addr del $ip_maj/24 dev br0
>>brctl delbr br0
>>ip link set dev $dev down
>>ip addr del $ip_min/24 dev $dev
>>ip addr del $ip_maj/24 dev $dev
>>echo ""
>> }
>>
>> set_hostname_and_localhost(){
>>echo "Setting hostname and localhost"
>>hostname=`grep -v "^\s*#" /etc/hostname | head -n1`
>>ip link set dev lo up
>>echo ""
>> }
>>
>> create_phys_device_link(){
>>dev=$1
>>echo Creating device link for $dev
>>ip link set dev $dev up
>>echo ""
>> }
>>
>> set_phys_device_addr(){
>>dev=$1
>>ip_maj=$2
>>ip_min=$3
>>gateway=$4
>>echo -n "Setting physical device addresses "
>>echo -n "$ip_maj "
>>echo -n "and $ip_min "
>>echo -n "for $physdev "
>>echo "with gateway $gateway"
>>ip link set dev $dev down
>>ip addr add $ip_maj/24 dev $dev
>>ip addr add $ip_min/24 dev $dev
>>ip link set dev $dev
Re: Hello I am a user
Quantum Universe writes: > I want qemu developer.how can i be what should i learn The website give a few pointers: https://www.qemu.org/contribute/ And we have a slowly growing developer manual that talks about various subsystems: https://qemu.readthedocs.io/en/latest/devel/index.html Was there any particular area you are interested in? -- Alex Bennée
Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0
Can you try this please:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
?
On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> I found the commit that breaks my VM. Anybody has any background on why it was
> done? The comments are fairly extensive, but they are Mac related and I am
> running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change definitely
> breaks Windows 10. Anything before I can check out, compile and it runs fine.
> Anything after this commit and it produces that boot device inaccessible
> error.
> Reverting this change on the current master also makes it work fine.
>
> git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> af1b80ae56c9495999e8ccf7b70ef894378de642
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index b7bc2a..7a5a8b3521 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> dev = aml_device("PCI0");
> aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
> aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> aml_append(sb_scope, dev);
> aml_append(dsdt, sb_scope);
>
> @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
> aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
> aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> aml_append(dev, build_q35_osc_method());
> aml_append(sb_scope, dev);
> aml_append(dsdt, sb_scope);
>
> It looks like a regression issue in 5.2.x so I registered a bug for it:
> https:/
> /bugs.launchpad.net/qemu/+bug/1917565
>
>
> On Sun, Feb 28, 2021 at 9:13 PM Nick S wrote:
>
>
> I have a VM set up on a USB SSD drive that I assign directly using linux
> device (-blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/
>
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
>
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
>
> I've been using it for a few years now and recently decided to compile the
> most recent version of qemu to do some hacking. To my surprise, when I
> compiled the master branch, Windows failed to load with the "Boot Device
> Inaccessible" error. I went through tags in git and the latest tag that
> works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was something
> changed recently for passing a linux block device as "raw"?
>
> Thank you,
> Nick
>
How to start an armv8 machine in EL3?
Hello all, I found out in a baremetal program I run for qemu aarch64 'virt' machine (cpu is cortex-a72), the "msr sp_el1, x0" instruction causes trap making PC jump to 0x200 which is the vector address for synchronous exception, from current EL while using SP_ELx (if the vector base address was 0, which is the case). (Ref : https://developer.arm.com/documentation/102412/0100/The-vector-tables ) When I read the 'EL' value by 'msr x8, currentel', x8 became '0x4' so it is EL1 (https://community.arm.com/developer/ip-products/processors/f/cortex-a-forum /10303/armv8-a-currentel-register-definition) How come cortex-a72 machines started at EL1? And if I want to make the virtual machine start at EL3 (this baremetal code assumes it should be in EL3 after reset, and it runs ok in rtl sim.), what should I do? Thank you very much for reading. Chan Kim
