On my SKL/KBL machine, upstream 4.12 kernel dom0 couldn't boot up using
xen.efi which is xen 4.9
(1) Upstream 4.11 kernel doesn't have such issue.
(2) Upstream 4.12 kernel on my native uefi machine could boot up.
After some debug, I have some finding:
firmware/efi.c: Reinit efi global
> On 24/07/17 17:42, Alexey G wrote:
> > Hi,
> >
> > On Mon, 24 Jul 2017 10:53:16 +0100
> > Igor Druzhinin wrote:
> >>> [Zhang, Xiong Y] Thanks for your suggestion.
> >>> Indeed, if I set mmi_hole >= 4G - RMRR_Base, this could fix my issue
> On Mon, 24 Jul 2017 08:07:02 +
> "Zhang, Xiong Y" wrote:
>
> > [Zhang, Xiong Y] Thanks for your suggestion.
> > Indeed, if I set mmi_hole >= 4G - RMRR_Base, this could fix my issue.
> > For this I still have two questions, could you help me ?
>
> On 24/07/17 09:07, Zhang, Xiong Y wrote:
> >>> On Fri, 21 Jul 2017 10:57:55 +0000
> >>> "Zhang, Xiong Y" wrote:
> >>>
> >>>> On an intel skylake machine with upstream qemu, if I add
> >>>> "rdm=strategy=host,
> > On Fri, 21 Jul 2017 10:57:55 +
> > "Zhang, Xiong Y" wrote:
> >
> > > On an intel skylake machine with upstream qemu, if I add
> > > "rdm=strategy=host, policy=strict" to hvm.cfg, win 8.1 DomU couldn't
> > > b
On an intel skylake machine with upstream qemu, if I add "rdm=strategy=host,
policy=strict" to hvm.cfg, win 8.1 DomU couldn't boot up and continues reboot.
Steps to reproduce this issue:
1) Boot xen with iommu=1 to enable iommu
2) hvm.cfg contain:
builder="hvm"
memory=
disk=[
To: Anthony PERARD
> Cc: xen-de...@lists.xensource.com; ian.jack...@eu.citrix.com; Zhang, Xiong Y
>
> Subject: Re: [Xen-devel] [PATCH] hw/pt-graphics.c: Gave guest iomem
> permission for host opregion in qemu-xen-traditional
>
> Hi,
>
> Perhaps Anthony can review this pa
signed long
> gfn)
> >
> > I think while we're renaming this I'd rename this to ept_do_recalc().
>
> Which gets me to ask (once again) what purpose the ept_ prefix
> has for a static function. I'd rather see this called do_recalc(), and
> the p2m-pt variant coul
> On 08/05/17 11:52, Zhang, Xiong Y wrote:
> >>>>> On 06.05.17 at 03:51, wrote:
> >>>>>>> On 05.05.17 at 05:52, wrote:
> >>>>> 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> >>>>> outstan
couldn't work. Then
> >> > ioreq.entry_count is larger than zero after an ioreq server unmaps,
> >> > finally this results DomU couldn't reboot.
> >>
> >> I've had trouble understanding this part already on v1 (btw, why is
> >> this
#x27;t reboot.
>
> I've had trouble understanding this part already on v1 (btw, why is
> this one not tagged v2?), and since I still can't figure it I have to ask:
> Why is it that guest reboot is being impacted here? From what I recall
> a non-zero count should only prevent
eve the currently recorded type instead of the
> mandated active one. Another might be to relax
> p2m_finish_type_change()'s old type check, accepting that this
> would lead to unnecessary calls to p2m_change_type_one(). It
> may be possible to avoid some of the extra overhead by e.g.
>
p2m_type_t ot, p2m_type_t nt)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +p2m_type_t t;
> +unsigned long gfn = gfn_x(first_gfn);
> +unsigned long last_gfn = gfn + max_nr - 1;
> +
> +ASSERT(ot != nt);
> +ASSERT(p2m_is_changeable(ot) &a
; > 1. Should we enable 5 level paging for PV guest ? (You are discussing)
> > 2. Should we make the 5 level paging and 4 level paging supported with one
> binary?
[Zhang, Xiong Y] If we plan to enable 5 level paging at runtime, we have to
reconstruct xen mm code first as some consta
14 matches
Mail list logo
