From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Ruh <jan.ruh@tttech.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Kernel requires x86-64 CPU, after modifying arch_shared_info struct
Date: Mon, 29 Jun 2020 11:18:23 +0200 [thread overview]
Message-ID: <20200629091823.GF735@Air-de-Roger> (raw)
In-Reply-To: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com>
On Mon, Jun 29, 2020 at 07:43:43AM +0000, Jan Ruh wrote:
> Hi Xen Dev Community,
>
>
> I ran into an issue when implementing a prototype for a new
> paravirtualized clock for x86-64 hosts. I extended the
> arch_shared_info struct by 6 fields totaling at 36 bytes. I updated
> the xen-foreign/references.size to represent the new size of the
> arch_shared_info struct. The fields are correctly updated in Xen and
> I am also able to read the correct information stored from dom0.
> However, if I try to start a hvm VM with pvh extensions it does not
> boot telling me that "This kernel requires an x86-64 CPU, but only
> detected an i686 CPU.".
Did you try backing up your changes and seeing if the same happens?
Did you rebuild both the Xen hypervisor and the tools?
> I have rebuild my Linux domU kernel just as
> the dom0 kernel and everything should be compatible. To me this
> looks like Xen or libxc does some compatibility checks before
> booting up my HVM domU and decides to downgrade the detectable CPU
> due to some issue that I am not aware of. Do I miss something?
Pasting your xl config file would be helpful in order to help debug.
> Is my
> approach to extend the arch_shared_info wrong in the first place?
Doesn't look directly related to a change in arch_shared_info IMO, but
it's hard to tell without having more info.
Posting your changes might also help spot something wonky.
> CONFIDENTIALITY: The contents of this e-mail are confidential and
> intended only for the above addressee(s). If you are not the
> intended recipient, or the person responsible for delivering it to
> the intended recipient, copying or delivering it to anyone else or
> using it in any unauthorized manner is prohibited and may be
> unlawful. If you receive this e-mail by mistake, please notify the
> sender and the systems administrator at straymail@tttech.com
> immediately.
Nit: posting confidentiality banners to a public mailing lists
messages is kind of award, as the emails are publicly available for
anyone to read, even those that are not recipients of xen-devel, ie:
https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg01868.html
Roger.
next prev parent reply other threads:[~2020-06-29 9:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 7:43 Kernel requires x86-64 CPU, after modifying arch_shared_info struct Jan Ruh
2020-06-29 9:18 ` Roger Pau Monné [this message]
2020-06-29 9:56 ` AW: " Jan Ruh
2020-06-29 10:17 ` Roger Pau Monné
2020-06-30 7:30 ` AW: " Jan Ruh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200629091823.GF735@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=jan.ruh@tttech.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.