RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin
> Sent: Thursday, April 27, 2017 00:14
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> > On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> > > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > >> > From: John Baldwin [mailto:j...@freebsd.org]
> > >> > Sent: Thursday, April 20, 2017 02:34
> > >> > > Can we add the support of "ACPI0004" with the below one-line
> change?
> > >> > >
> > >> > >  acpi_sysres_probe(device_t dev)
> > >> > >  {
> > >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004",
> NULL };
> > >> > >
> > >> > Hmm, so the role of C01 and C02 is to reserve system resources,
> though we
> > >> > in turn allow any child of acpi0 to suballocate those ranges (since
> historically
> > >> > c01 and c02 tend to allocate I/O ranges that are then used by things
> like the
> > >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in
> the ACPI
> > >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> > >> > particular, it
> > >> > seems that 004 should only allow direct children to suballocate?  This
> > >> > change might work, but it will allow more devices to allocate the
> ranges in
> > >> >  _CRS than otherwise.
> > >> >
> > >> > Do you have an acpidump from a guest system that contains an
> ACPI0004
> > >> > node that you can share?
> > >> >
> > >> > John Baldwin
> > >>
> > >> Hi John,
> > >> Thanks for the help!
> > >>
> > >> Please see the attached file, which is got by
> > >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> > >>
> > >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> > >> "VMBus" (VMBS).
> > >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> > >> see the length of the MMIO range in the dumped asl code, it does have
> > >> a 512MB MMIO range [0xFE000, 0xF].
> > >>
> > >> It looks FreeBSD can't detect ACPI0004 automatically.
> > >> With the above one-line change, I can first find the child device
> > >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> > >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> > >>
> > >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> > >> we can add a new small driver for ACPI0004, just like we added VMBus
> > >> driver as a child device of acpi0?
> > >
> > > Hmmm, so looking at this, the "right" thing is probably to have a device
> > > driver for the ACPI0004 device that parses its _CRS and then allows its
> > > child devices to sub-allocate resources from the ranges in _CRS.  However,
> > > this would mean make VMBus be a child of the ACPI0004 device.
> Suppose
> > > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0'
> device
> > > would need to create a child device for all of its child devices.  Right
> > > now acpi0 also creates devices for them which is somewhat messy (acpi0
> > > creates child devices anywhere in its namespace that have a valid _HID).
> > > You can find those duplicates and remove them during acpi_module0's
> attach
> > > routine before creating its own child device_t devices.  (We associate
> > > a device_t with each Handle when creating device_t's for ACPI handles
> > > which is how you can find the old device that is a direct child of acpi0
> > > so that it can be removed).
> >
> > The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> > hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> > we did to the hyper-v's pcib0.
> 
> The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> should probably be doing is only creating device_t nodes for immediate
> children.  This would require an ACPI-aware isa0 for LPC devices below
> the ISA bus in the ACPI namespace.  We haven't done that in part because
> BIOS vendors are not always consistent in placing LPC devices under an
> ISA bus.  However, you otherwi

RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Thursday, April 20, 2017 02:34
> > Can we add the support of "ACPI0004" with the below one-line change?
> >
> >  acpi_sysres_probe(device_t dev)
> >  {
> > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };
> >
> Hmm, so the role of C01 and C02 is to reserve system resources, though we
> in turn allow any child of acpi0 to suballocate those ranges (since 
> historically
> c01 and c02 tend to allocate I/O ranges that are then used by things like the
> EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the ACPI
> 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
> seems that 004 should only allow direct children to suballocate?  This
> change might work, but it will allow more devices to allocate the ranges in
>  _CRS than otherwise.
> 
> Do you have an acpidump from a guest system that contains an ACPI0004
> node that you can share?
> 
> John Baldwin

Hi John,
Thanks for the help!

Please see the attached file, which is got by
"acpidump -dt | gzip -c9 > acpidump.dt.gz"

In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
"VMBus" (VMBS). 
It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
see the length of the MMIO range in the dumped asl code, it does have
a 512MB MMIO range [0xFE000, 0xF].

It looks FreeBSD can't detect ACPI0004 automatically.
With the above one-line change, I can first find the child device 
acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.

If you think we shouldn't touch acpi_sysresource0 here, I guess
we can add a new small driver for ACPI0004, just like we added VMBus
driver as a child device of acpi0?

-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware
ID is "ACPI0004".  The module device has a _CRS object defining some MMIO
ranges, which are needed when physical PCIe devices are passed through
to the VM.

Currently it looks FreeBSD doesn't make use of the ACPI module device and
hence the _CRS object can't be easily retrieved by Hyper-V VMBus driver.

Can we add the support of "ACPI0004" with the below one-line change?

Looking forward to your suggestion!

--- a/sys/dev/acpica/acpi_resource.c
+++ b/sys/dev/acpica/acpi_resource.c
@@ -653,7 +653,7 @@ MODULE_DEPEND(acpi_sysresource, acpi, 1, 1, 1);
 static int
 acpi_sysres_probe(device_t dev)
 {
-static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
+static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };

 if (acpi_disabled("sysresource") ||
ACPI_ID_PROBE(device_get_parent(dev), dev, sysres_ids) == NULL)

Thanks,
-- Dexuan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Toomas Soome
>
> IMO there are multiple issues around this problem and workaround.
>
> First of all, to control UEFI memory allocation, the AllocatePages() has 
> options:
>
> AllocateAnyPages,
> AllocateMaxAddress,
> AllocateAddress
>
> On x86, we use:
>
> staging = 1024*1024*1024;
> status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> nr_pages, );
>
> Which means:
>
> "Allocation requests of Type AllocateMaxAddress allocate any available range 
> of
> pages whose uppermost address is less than or equal to the address pointed to
> by Memory on input.”
>
> So, we are asking for an amount of memory (64MB), with condition that all the
> pages should be below 1GB.
>
> And we get it. If hyper-v is in fact returning us memory from already occupied
> area - there can be exactly one conclusion - it is bug in hyper-v.

Hyper-V has no bug here: Hyper-V doesn't return memory from already occupied
area. The issue is: the loader here tries to write the 64MB staging area (BTW, 
it's
48MB in 10.3) into the physical memory range [2MB, 2MB+64MB) -- the loader
assumes this range is writable. However, this is not true with Hyper-V EFI
firmware: there is a read-only BootServicesData memory block starting at
about 47.449MB, causing a crash in the loader.

If you're interested, the whole long story is in the below link.  :-)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746, e.g. please see the
screenshot in comment #8.


> Note, this allocation method does *not* set the starting point for 
> allocation, it
> can return us *any* chunk of memory of given size, below 1GB.
Yes. This can potentially cause new issues...

> So the attempt to control such allocation by size, is unfortunately flawed - 
> it
> really does not control the allocation.
Yes, you're correct.
The patch is flawed. I only expect (or hope) it can work around the issues with
typical Hyper-V UEFI firmware.
In my test, it works with Hyper-V 2012 R2 and 2016.
I hope it could work in future Hyper-V too...

> Note that I have also seen AllocateAddress failures - there was nicely 
> available
> chunk of memory, but the firmware just did not allocate with given address (it
> did happen with OVMF + qemu).
>
> The secondary flaw there is also about firmware. Sure, with UEFI you can have
> “random” allocations and the actual control over memory is actually problem,
> but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS
> will live - IMO this is just stupid.
>
> The only real solution here is to either rise the MaxAddress limit or use
> AllocateAnyPages, get kernel loaded into the memory, and after switching off
> the boot services and before jumping to kernel, relocate the kernel to 
> available
> location below 1GB…
Yes. IMO the biggest issue is that currently the kernel can't be relocated... 
:-(
It's a long term work to make it relocatable, I'm afraid.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Pete Wright
> Sent: Thursday, March 9, 2017 14:04
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
> On 3/8/17 10:00 PM, Dexuan Cui wrote:
> > For now, I suggest we should only apply the idea "reduce the size of the
> > staging area if necessary" to VM running on Hyper-V, we should restore the
> > old behavior on physical machines since that has been working for people
> > for a long period of time, though it's  potentially unsafe.
> >
> +1
> 
> i'd like to see the old behaviour for physical machines to be restored
> as well since this has rendered my drm-next test rig broken :(
> 
> -pete

Eventually I committed 314956 for the issue:
https://svnweb.freebsd.org/base?view=revision=314956
The old behaviour for physical machines are restored.

PS, I understand usually I should put the patch on phabricator for review,
before it's committed, but since the issue here is critical, I committed it
directly to unblock people first. Sorry.
Please comment on the patch if you think it needs rework  -- I hope not. :-) 

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hi Roberto, 
Thanks for sending me your memmap and this is a temporary workaround
patch for you:
https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch

I put the memmap info here for people who're interested:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26

We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
loader.efi just writes into this range by force -- this is unsafe anyway!

To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
that would require a lot of complicated long term work:
https://reviews.freebsd.org/D9686?id=25414#inline-56969

For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.

I think in the loader we can use CPUID to tell if we're running on Hyper-V or 
not.

Thanks,
-- Dexuan

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Sent: Thursday, March 9, 2017 10:44
> To: Roberto Rodriguez Jr <rob.rodz@gmail.com>
> Cc: FreeBSD Current <freebsd-current@freebsd.org>
> Subject: RE: input/output error @boot
> 
> [This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> Hmm, Alex did report 314891 worked.
> 
> Can you please post the full boot log of the loader?
> Especially, when you see the “OK” prompt, can you please run the “memmap”
> command like this link ...
> 
> You can take a photo of the screen and send it to me, if it’s too big.
> 
> Thanks,
> -- Dexuan
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hmm, Alex did report 314891 worked.

Can you please post the full boot log of the loader?
Especially, when you see the “OK” prompt, can you please run the “memmap” 
command like this link
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065090.html ?

You can take a photo of the screen and send it to me, if it’s too big.

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Thursday, March 9, 2017 10:34
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

314916 same error :(
input/output
cannot load file
elf64_loadimage read failed
oh well

On Mar 7, 2017 9:58 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix the 
off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr 
[mailto:rob.rodz@gmail.com<mailto:rob.rodz@gmail.com>]
Sent: Tuesday, March 7, 2017 21:27

To: Dexuan Cui <de...@microsoft.com<mailto:de...@microsoft.com>>
Cc: FreeBSD Current 
<freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org>>
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D=0>
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D=0>

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix the 
off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Tuesday, March 7, 2017 21:27
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D=0>
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D=0>

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Hello Dexuan,
> This issue reproduced at least for 4 different HW platform
> How can I help you resolve this issue ?
> 
> The same result for r314862:

Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix
the off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Sent: Wednesday, March 8, 2017 09:39
> To: Dexuan Cui <de...@microsoft.com>; freebsd-current  curr...@freebsd.org>
> Cc: Chris H <bsd-li...@bsdforge.com>; AN <a...@neu.net>; Ngie Cooper
> (yaneurabeya) <yaneurab...@gmail.com>; Michael Tuexen
> <tue...@freebsd.org>; Roberto Rodriguez Jr <rob.rodz@gmail.com>; Guido
> Falsi <m...@madpilot.net>; Warner Losh <i...@bsdimp.com>; Ultima
> <ultima1...@gmail.com>; Sepherosa Ziehau <se...@freebsd.org>
> Subject: Re: Boot failure - svn up from this morning
> 
> Hello Dexuan,
> 
> This issue reproduced at least for 4 different HW platform:
> 
> Supermicro 6037R-TXRF
> Supermicro A1SRM-2758F
> Supermicro X9SCM-F
> Gigabyte GA-C1037UN-EU
> 
> How can I help you resolve this issue ?
> 
> Thank you!
> 
> The same result for r314862:

Weird... :-(
I'm looking at the code again. Will report back soon.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
> 
> Please let me know in case this can't solve the issue.
 
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
> 
> Please let me know in case this can't solve the issue.
 
Sorry, r314770  has a bug, so I had to commit r314828 for this:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

Hi Roberto,
I’m not sure if the snapshot is built daily or weekly.

To have this latest fix, I suggest you re-buildworld.
If you have done buildworld in your local directory, then you only need to 
rebuild the EFI loader:

'wget' the patch 
(https://github.com/freebsd/freebsd/commit/f61d2c287970bdfb013deafb416e82a844415031.patch)
cd' into your FREEBSD_SOURCE_ROOT/sys/boot/ and run "patch -p3 < 
the_patch_name".
If you have run 'make buildworld", just run 'make' in the sys/boot/ directory 
and copy the new loader.efi into the boot folder, e.g. in my side, I use
cp -iv  /usr/obj/root/bsd.git/sys/boot/efi/loader/loader.efi /boot/loader.efi

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Monday, March 6, 2017 20:33
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

Hey I do appreciate the work and time put into this issue. I will update my 
sources when I chroot from the USB, need to find out how first, ;) and do I 
rebuildworld  or just download the lastest head snapshot? Im new to testing 
with others. Thank you very much
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Hi Chris,
> Thank you very much for the screenshots!!!
> 
> On the host there is a 1MB LoaderData memory range, which splits
> the big Conventional Memory range into a small one (15MB) and a
> big one: the small one is too small to hold the staging area.
> 
> I'm going to post a patch shortly.

Can you please try the below patch?
https://reviews.freebsd.org/D9904
You can find the URL of the "Download Raw Diff" in the page and
'wget' the patch and then apply it.

It should be able to fix the recent UEFI-boot issue introduced by me.

You may not need to re-buildworld. Please this link to replace the
bad 'loader.efi':
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html

I'm planning to commit the patch later today in about 6 hours, because
I'm pretty confident in the patch and it should fix the critical issue...

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Dexuan Cui
> Sent: Monday, March 6, 2017 13:10
> Can you please try the below patch?
> https://reviews.freebsd.org/D9904
> You can find the URL of the "Download Raw Diff" in the page and
> 'wget' the patch and then apply it.
> 
> It should be able to fix the recent UEFI-boot issue introduced by me.
> 
> You may not need to re-buildworld. Please this link to replace the
> bad 'loader.efi':
> https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html
> 
> I'm planning to commit the patch later today in about 6 hours, because
> I'm pretty confident in the patch and it should fix the critical issue...

I committed r314770 just now to minimize the impact:
https://svnweb.freebsd.org/base?view=revision=314770

Please let me know in case this can't solve the issue.

 Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

> From: Dexuan Cui
> Sent: Monday, March 6, 2017 14:35
> To: 'Roberto Rodriguez Jr' <rob.rodz@gmail.com>; freebsd-
> curr...@freebsd.org
> Subject: RE: input/output error @boot
> 
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Roberto Rodriguez Jr
> > Sent: Monday, March 6, 2017 04:05
> > To: freebsd-current@freebsd.org
> > Subject: Re: input/output error @boot
> >
> > When I get to the house I'll try to patch it and see if I get any results.
> > Thank u very much
> 
> Hi Roberto,
> I posted https://reviews.freebsd.org/D9904 to fix the issue.
> It would be great if you can try this patch directly.
> 
> I'm planning to commit the patch to the HEAD in ~3 hours.
 
I committed r314770 just now to minimize the impact:
https://svnweb.freebsd.org/base?view=revision=314770

Please let me know in case this can't solve the issue.

 Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Roberto Rodriguez Jr
> Sent: Monday, March 6, 2017 04:05
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
> 
> When I get to the house I'll try to patch it and see if I get any results.
> Thank u very much

Hi Roberto, 
I posted https://reviews.freebsd.org/D9904 to fix the issue.
It would be great if you can try this patch directly.

I'm planning to commit the patch to the HEAD in ~3 hours.

Thanks,
-- Dexuan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Hi Chris,
> Thank you very much for the screenshots!!!
> 
> On the host there is a 1MB LoaderData memory range, which splits
> the big Conventional Memory range into a small one (15MB) and a
> big one: the small one is too small to hold the staging area.
> 
> I'm going to post a patch shortly.

(Some of you may receive this same mail twice or even thrice -- sorry
for the confusion, it's because my first mail "is being held until the
list moderator can review it for approval" due to "Too many recipients
to the message"...)

Can you please try the below patch?
https://reviews.freebsd.org/D9904
You can find the URL of the "Download Raw Diff" in the page and
'wget' the patch and then apply it.

It should be able to fix the recent UEFI-boot issue introduced by me.

You may not need to re-buildworld. Please this link to replace the
bad 'loader.efi':
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html

I'm planning to commit the patch later today in about 6 hours, because
I'm pretty confident in the patch and it should fix the critical issue...

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> Sent: Monday, March 6, 2017 09:57
> > Thanks! I'm eager to see your screenshots.
> > The line whose "Physical" address contains 2MB is the most interesting to 
> > me.
> > And please at least post the other lines around the line.
> OK. Her you go. It's taken me some time to get any shots
> that are readable -- I don't have a very steady hand. :-(
> Anyway, I haven't touched them. They're just as my phone camera
> produced them. Because of their size, I've packed them all up.
> I'm afraid I don't know their exact order. Hopefully you'll
> know by looking at them. :-)
> They're located at: bsdforge.com/efi-memmap.tar.xz

Hi Chris, 
Thank you very much for the screenshots!!!

On the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.

I'm going to post a patch shortly.

For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> OK copying the boot.efi from the install DVD will only
> hose the system (EFI).
Do you mean copying the boot.efi from the install DVD doesn't work?
If so we need to build a good boot.efi with the CURRENT code + reverting
the offending commit.

> So how long till (u)efi is again supported on FreeBSD?
> Sorry for the frustration. But getting a working FreeBSD
> on this system has become an unusually long, and expensive
> process, this time around -- even for CURRENT.
> 
> --Chris

I think EFI boot has been supported by FreeBSD for years and it's only
broken since last Thursday by my patch... Sorry. Let's make it
right soon, once I understand why the patch breaks it  by checking
the memory maps on your system.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> > Hi Alex,
> > Thanks for the info!
> > Unluckily it looks the delay() in my patch didn't work here somehow, so the
> > screen scrolled up so quickly that we're unable to see the output clearly...
> > :-(
> >
> > Luckily we can use this new method:
> > When you reach the "OK " prompt in your screenshot
> > please run "memmap" command
> > and share the output with me. Please press space to show the complete  info
> > and  share the screenshots.
> >
> > E.g. in my side, the memmap command shows:
> I'm experiencing the same problem.
> I've taken several screen shots, but not sure I got all of them.
> I guess the first, and last will maybe the most important. I'll
> clean them up, and post a link to them.

Thanks! I'm eager to see your screenshots. 
The line whose "Physical" address contains 2MB is the most interesting to me.
And please at least post the other lines around the line.

> In the meantime, is there any way to get the system to boot again?
> Is it possible to simply boot the install DVD, and replace the
> efi image on the system, with the one on the install DVD. Or
> can the offending commit simply be reverted.
> 
> --Chris
Yes, you can replace the broken system's bad /boot/loader.efi  with a
good version. You can also revert the offending commit ("loader.efi: reduce
the size of the staging area if necessary").

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter
> Sent: Sunday, March 5, 2017 03:32
> 
> Hello,
> 
> Screenshot: boot with patched loader:
> Video: boot with patched loader:

Hi Alex,
Thanks for the info! 
Unluckily it looks the delay() in my patch didn't work here somehow, so the 
screen
scrolled up so quickly that we're unable to see the output clearly... :-(

Luckily we can use this new method:
When you reach the "OK " prompt in your screenshot
 (http://picpaste.com/IMG_1768-PnmZAtBZ.JPG), please run "memmap" command
and share the output with me. Please press space to show the complete  info and 
share the screenshots.

E.g. in my side, the memmap command shows:

  Type Physical  Virtual   #Pages Attr
 ConventionalMemory   0080 UC WC WT WB
   BootServicesData 0008  0001 UC WC WT WB
 ConventionalMemory 00081000  001f UC WC WT WB
   BootServicesData 0010  0020 UC WC WT WB
 ConventionalMemory 0012  2e53 UC WC WT WB
   BootServicesData 02f73000  118d UC WC WT WB
 ConventionalMemory 0410  00037f00 UC WC WT WB
 LoaderData 3c00  4000 UC WC WT WB
 ConventionalMemory 4000  000b0adf UC WC WT WB
 LoaderData f0adf000  4000 UC WC WT WB
 LoaderCode f4adf000  0072 UC WC WT WB
 LoaderData f4b51000  217b UC WC WT WB
 LoaderCode f6ccc000  001d UC WC WT WB
  ACPIReclaimMemory f6ce9000  0001 UC WC WT WB
   Reserved f6cea000  0007 UC WC WT WB
  ACPIReclaimMemory f6cf1000  0001 UC WC WT WB
RuntimeServicesData f6cf2000  0029 UC WC WT WB
 ConventionalMemory f6d1b000  0890 UC WC WT WB
   BootServicesData f75ab000  0017 UC WC WT WB
 ConventionalMemory f75c2000  0001 UC WC WT WB
   BootServicesData f75c3000  000d UC WC WT WB
 ConventionalMemory f75d  000c UC WC WT WB
 --more--   page down  line down  quit

Thanks,
-- Dexuan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Michael Tuexen
> Sent: Friday, March 3, 2017 21:30
> > BTW, I understand it's really annoying to boot the host first...
> > I'm really sorry for this.
> >
> > I suppose you're able to build or find a good 'loader.efi' binary on 
> > another host,
> > and  then manage to replace the bad 'loader.efi' on the host broken by me. 
> > :-)
> This problem also occurred on a Dell R430...
> 
> Best regards
> Michael

Can you please use the patch to dump the EFI memory map:
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html

Let's get this fixed ASAP.

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Dexuan Cui
> Sent: Friday, March 3, 2017 19:50
> > From: Alex Deiter
> > Sent: Friday, March 3, 2017 17:22
> > Hello,
> > The same issue with FreeBSD 12.0-CURRENT-r314563:
> > elf64_loadimage: could not read symbols - skipped!
> >
> > I suspect regression after:
> >
> > Revision 314547 - Directory Listing
> > Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> > loader.efi: reduce the size of the staging area if necessary
> 
> Yes, I believe the issue is caused by the patch, which is supposed to PR 
> 211746:
> ...
> Can you please try the patch to dump the memory map?
> ...

BTW, I understand it's really annoying to boot the host first...
I'm really sorry for this.

I suppose you're able to build or find a good 'loader.efi' binary on another 
host,
and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter
> Sent: Friday, March 3, 2017 17:22
>
> Hello,
> The same issue with FreeBSD 12.0-CURRENT-r314563:
> elf64_loadimage: could not read symbols - skipped!
>
> I suspect regression after:
>
> Revision 314547 - Directory Listing
> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> loader.efi: reduce the size of the staging area if necessary

Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746

Sorry for causing the issue to you, but I suspect the patch reveals a bug in 
your
host's firmware: the memory map reported by the host's firmware may be
incorrect.

Can you please try the patch to dump the memory map?
https://github.com/dcui/freebsd/commit/6094aac8ac9bddb24e3ac45493ac020c94029ce8.patch

And the patch will allow your host to boot.
Note: there is a 10-second pause every time 5 lines are printed. This is to make
sure we have enough time to take a screenshot or photo. :-)

About how to apply the patch and build/install it:
'wget' the above patch, and 'cd' into your FREEBSD_SOURCE_ROOT/sys/boot/ and run
"patch -p3 < the_patch_name". If you have run 'make buildworld", just run 
'make' in the
sys/boot/ directory and copy the new loader.efi into the boot folder, e.g. in 
my side, I
use
cp -iv  /usr/obj/root/bsd.git/sys/boot/efi/loader/loader.efi /boot/loader.efi

Thanks,
-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: FreeBSD_HEAD_amd64_gcc - Build #1717 - Still Failing

[Dexuan Cui]

This failure should already been fixed by

r308799 | dexuan | 2016-11-18 16:15:45 +0800 (Fri, 18 Nov 2016) | 9 lines
fix share/man/man4/Makefile for hv_ata_pci_disengage.4

Sorry for the trouble!

Thanks,
-- Dexuan


> -Original Message-
> From: jenkins-ad...@freebsd.org [mailto:jenkins-ad...@freebsd.org]
> Sent: Friday, November 18, 2016 17:02
> To: dex...@freebsd.org; jenkins-ad...@freebsd.org; freebsd-
> curr...@freebsd.org
> Subject: FreeBSD_HEAD_amd64_gcc - Build #1717 - Still Failing
> 
> FreeBSD_HEAD_amd64_gcc - Build #1717 - Still Failing:
> 
> Build information:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.Fr
> eeBSD.org%2Fjob%2FFreeBSD_HEAD_amd64_gcc%2F1717%2F=02%7C01
> %7Cdecui%40microsoft.com%7Ca35250eac7f34b2bd84b08d40f919f57%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636150565497725588=c
> dLp5D53eR3C0%2BkKLPw2W4Ek2BxW3f9swEPuPpM1Tpw%3D=0
> Full change log:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.Fr
> eeBSD.org%2Fjob%2FFreeBSD_HEAD_amd64_gcc%2F1717%2Fchanges=0
> 2%7C01%7Cdecui%40microsoft.com%7Ca35250eac7f34b2bd84b08d40f919f57
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636150565497735597
> =TXNiwwKo76pnEVsdUQm92Hmhoh%2Brk2RD8j6ZwcUNAoQ%3D
> ved=0
> Full build log:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.Fr
> eeBSD.org%2Fjob%2FFreeBSD_HEAD_amd64_gcc%2F1717%2Fconsole=0
> 2%7C01%7Cdecui%40microsoft.com%7Ca35250eac7f34b2bd84b08d40f919f57
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636150565497735597
> =U29ADeCu9mMcnz4a8Ez6pR%2FhzQHXc4bD%2FJtkrReIOVQ%3D
> ved=0
> 
> Change summaries:
> 
> 308798 by dexuan:
> remove the hv_ata_pci_disengage(4) manual
> 
> A few months ago, we removed the driver, which was not necessary any longer.
> 
> Reviewed by:  sephe
> Approved by:  sephe (mentor)
> MFC after:1 week
> Sponsored by: Microsoft
> 
> 308797 by dexuan:
> update the hv_vmbus(4) manual by adding a dependency on pci
> 
> We enhanced the vmbus driver to support PCIe pass-through recently.
> 
> Reviewed by:  sephe
> Approved by:  sephe (mentor)
> MFC after:1 week
> Sponsored by: Microsoft
> 
> 308795 by dexuan:
> hyperv/pcib: change the file name: pcib.c -> vmbus_pcib.c
> 
> This makes the file name and the variable naming in the file consistent.
> 
> Reviewed by:  sephe
> Approved by:  sephe (mentor)
> MFC after:1 week
> Sponsored by: Microsoft
> 
> 308794 by dexuan:
> hyperv/vmbus,pcib: Add MODULE_DEPEND on pci
> 
> We'd better add this dependency explicitly, though usually the pci
> driver is built into the kernel by default.
> 
> Reviewed by:  sephe
> Approved by:  sephe (mentor)
> MFC after:1 week
> Sponsored by: Microsoft
> 
> 308793 by dexuan:
> hyperv/pcib: Fix the build for some kernel configs
> 
> Add the dependency on pci explicitly for the pcib and vmbus drivers.
> The related Makefiles are updated accordingly too.
> 
> Reviewed by:  sephe
> Approved by:  sephe (mentor)
> MFC after:1 week
> Sponsored by: Microsoft
> 
> 
> 
> The end of the build log:
> 
> [...truncated 146250 lines...]
> --- pthread_attr_get_np.3.gz ---
> gzip -cn
> /builds/FreeBSD_HEAD_amd64_gcc/share/man/man3/pthread_attr_get_np.3 >
> pthread_attr_get_np.3.gz
> --- pthread_attr_setcreatesuspend_np.3.gz ---
> gzip -cn
> /builds/FreeBSD_HEAD_amd64_gcc/share/man/man3/pthread_attr_setcreatesu
> spend_np.3 > pthread_attr_setcreatesuspend_np.3.gz
> --- pthread_barrierattr.3.gz ---
> gzip -cn
> /builds/FreeBSD_HEAD_amd64_gcc/share/man/man3/pthread_barrierattr.3 >
> pthread_barrierattr.3.gz
> --- pthread_barrier_destroy.3.gz ---
> gzip -cn
> /builds/FreeBSD_HEAD_amd64_gcc/share/man/man3/pthread_barrier_destroy.
> 3 > pthread_barrier_destroy.3.gz
> --- all_subdir_sbin ---
> --- ipf_l.o ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem
> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> /usr/include -
> L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tm
> p/usr/lib -
> B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tm
> p/usr/lib --
> sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_
> gcc/tmp -B/usr/local/x86_64-freebsd/bin/  -O2 -pipe -I. -DIPFILTER_BPF -
> DHAS_SYS_MD5_H   -
> I/builds/FreeBSD_HEAD_amd64_gcc/sbin/ipf/ipf/../../../contrib/ipfilter -
> I/builds/FreeBSD_HEAD_amd64_gcc/sbin/ipf/ipf/../../../contrib/ipfilter/tools -
> I/builds/FreeBSD_HEAD_amd64_gcc/sbin/ipf/ipf/../../../sys -
> I/builds/FreeBSD_HEAD_amd64_gcc/sbin/ipf/ipf/../../../sys/contrib/ipfilter -
> DSTATETOP -D__UIO_EXPOSE -DUSE_INET6 -g -MD  -MF.depend.ipf_l.o -
> MTipf_l.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-
> format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-format -Wno-
> error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-
> error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-
> error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-
> not-parentheses 

RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work

[Dexuan Cui]

Hi smokehydration,
Sephe has committed a few patches into 11-CURRENT to address the issue
and the details of the patches can be found at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208238

Can you please try today's Head branch?
We believe the issue should be fixed, and it would be great to have your 
confirmation.

Thanks,
-- Dexuan


> -Original Message-
> From: Dexuan Cui
> Sent: Friday, April 8, 2016 19:04
> To: 'Sepherosa Ziehau' <se...@freebsd.org>; smokehydrat...@tutanota.com
> Cc: freebsd-current@freebsd.org
> Subject: RE: Revision 297176 - hyperv/evttimer: Use an independent message
> slot so that it can work
> 
> Hi smokehydration,
> I guess your VM config file has something like "viridian = 1" or
> "viridian_enlightenment=xxx".
> 
> With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 100%
> Hyper-V.
> BTW, I know at least KVM can have the same behavior.
> 
> We have to find a reliable way to distinguish Hyper-V from other hypervisors
> that
> try to pretend to be Hyper-V...
> 
> Thanks,
> -- Dexuan
> 
> 
> > -Original Message-
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Sepherosa Ziehau
> > Sent: Friday, April 8, 2016 17:29
> > To: smokehydrat...@tutanota.com
> > Cc: freebsd-current@freebsd.org
> > Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent message
> > slot so that it can work
> >
> > I have reverted this change.  It will be brought back, after some code
> > refactoring.
> >
> > On Fri, Apr 8, 2016 at 4:22 PM,  <smokehydrat...@tutanota.com> wrote:
> > >
> > > Hello
> > >
> > > I recently update one of my many vms from an older CURRENT revision
> > r297196
> > > to r297659 and on reboot it just panics with the following:
> > >
> > > FreeBSD clang version 3.8.0 (tags/RELEHSE_380/final 262564) (based on
> LLVM
> > > 3.8.0
> > > )
> > > VT(vga): text 80x25
> > > Timecounter "Hyper-V" frequency 1000 Hz quality 1000
> > > Kernel trap 9 with interrupts disabled
> > >
> > >
> > > Fatal trap 9: general protection fault while in kernel mode
> > > cpuid = 0: apic id = 00
> > > instruction pointer = 0x20:0x8100d6?9
> > > stack pointer   = 0x28:ox820d5c30
> > > frame pointer   = 0x28:ox820d5c40
> > > code segment= base 0x0, limit 0xf, type 0x1b
> > > = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags= IOPL = 0
> > > current process = 0 ()
> > > [ thread pid 0 tid 0 ]
> > > stopped at  hv_get_timecount+0x9:   rdmsr
> > > db) wh
> > > Tracing pid 0 tid 0 td 0x81d0eff0
> > > hv_get_timecount() at hv_get_timecount+0x9/frame 0x820d5c40
> > > tc_init() at tc_init+0x251/frame 0x820d5c90
> > > mi_startup() at mi_startup+0x118/frame 0x820d5cb0
> > > btext() at btext+ox2c   =
> > > db>
> > >
> > > I changed hv_hv.c back to the previous revision (297176) and no panics 
> > > under
> > > Xen VM.
> > >
> > > Thanks!
> > >
> > > p.s. not sure why Xen gets detected as HyperV
> > >
> >
> >
> >
> > --
> > Tomorrow Will Never Die
> > ___
> > freebsd-current@freebsd.org mailing list
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.freebs
> > d.org%2fmailman%2flistinfo%2ffreebsd-
> >
> current=01%7c01%7cdecui%40microsoft.com%7c3a2924929b7b4158aa4f
> >
> 08d35f9043e2%7c72f988bf86f141af91ab2d7cd011db47%7c1=omVqiBrK
> > 9sWAd10koNsZkG72nSoXnjFdXKUsXhGFK6k%3d
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work

[Dexuan Cui]

> From: Konstantin Belousov [mailto:kostik...@gmail.com]
> Sent: Friday, April 8, 2016 22:02
> To: Dexuan Cui <de...@microsoft.com>
> Cc: Sepherosa Ziehau <se...@freebsd.org>; smokehydrat...@tutanota.com;
> freebsd-current@freebsd.org
> Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent message
> slot so that it can work
> 
> On Fri, Apr 08, 2016 at 11:03:46AM +, Dexuan Cui wrote:
> > Hi smokehydration,
> > I guess your VM config file has something like "viridian = 1" or
> > "viridian_enlightenment=xxx".
> >
> > With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 
> > 100%
> Hyper-V.
> > BTW, I know at least KVM can have the same behavior.
> >
> > We have to find a reliable way to distinguish Hyper-V from other hypervisors
> that
> > try to pretend to be Hyper-V...
> 
> At the time when the probe is done, the IDT entries for exceptions are
> already set. You can use rdmsr_safe() instead of rdmsr() to read Hyper-V
> timecounter register. Then, a fault definitely indicates that the kernel
> is not executing on the compatible Hyper-V emulator. Hopefully, a
> non-fault read is not impossible for undesired cases.

Hi Konstantin,
Thanks for the suggestion!

We're trying to solve the issue with "hv_features/hv_recommendations" of
some Hyper-V specific CPUIDs -- the other hypervisors are unlikely to touch
these CPUIDs; even if they do touch the CPUIDs, I think they should
respect the meanings of the CPUIDs and shouldn't incorrectly report
capabilities they doesn't really have.

A drafted patch is here:
https://github.com/howard0su/freebsd/commit/d1d031e0d8991ab1f94de00325705d266829c647
We'll clean up & post it

-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Revision 297176 - hyperv/evttimer: Use an independent message slot so that it can work

[Dexuan Cui]

Hi smokehydration,
I guess your VM config file has something like "viridian = 1" or
"viridian_enlightenment=xxx".

With this, Xen tries to pretend to be Hyper-V, but obviously Xen can't be 100% 
Hyper-V.
BTW, I know at least KVM can have the same behavior.

We have to find a reliable way to distinguish Hyper-V from other hypervisors 
that
try to pretend to be Hyper-V...

Thanks,
-- Dexuan


> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Sepherosa Ziehau
> Sent: Friday, April 8, 2016 17:29
> To: smokehydrat...@tutanota.com
> Cc: freebsd-current@freebsd.org
> Subject: Re: Revision 297176 - hyperv/evttimer: Use an independent message
> slot so that it can work
> 
> I have reverted this change.  It will be brought back, after some code
> refactoring.
> 
> On Fri, Apr 8, 2016 at 4:22 PM,   wrote:
> >
> > Hello
> >
> > I recently update one of my many vms from an older CURRENT revision
> r297196
> > to r297659 and on reboot it just panics with the following:
> >
> > FreeBSD clang version 3.8.0 (tags/RELEHSE_380/final 262564) (based on LLVM
> > 3.8.0
> > )
> > VT(vga): text 80x25
> > Timecounter "Hyper-V" frequency 1000 Hz quality 1000
> > Kernel trap 9 with interrupts disabled
> >
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 0: apic id = 00
> > instruction pointer = 0x20:0x8100d6?9
> > stack pointer   = 0x28:ox820d5c30
> > frame pointer   = 0x28:ox820d5c40
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= IOPL = 0
> > current process = 0 ()
> > [ thread pid 0 tid 0 ]
> > stopped at  hv_get_timecount+0x9:   rdmsr
> > db) wh
> > Tracing pid 0 tid 0 td 0x81d0eff0
> > hv_get_timecount() at hv_get_timecount+0x9/frame 0x820d5c40
> > tc_init() at tc_init+0x251/frame 0x820d5c90
> > mi_startup() at mi_startup+0x118/frame 0x820d5cb0
> > btext() at btext+ox2c   =
> > db>
> >
> > I changed hv_hv.c back to the previous revision (297176) and no panics under
> > Xen VM.
> >
> > Thanks!
> >
> > p.s. not sure why Xen gets detected as HyperV
> >
> 
> 
> 
> --
> Tomorrow Will Never Die
> ___
> freebsd-current@freebsd.org mailing list
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.freebs
> d.org%2fmailman%2flistinfo%2ffreebsd-
> current=01%7c01%7cdecui%40microsoft.com%7c3a2924929b7b4158aa4f
> 08d35f9043e2%7c72f988bf86f141af91ab2d7cd011db47%7c1=omVqiBrK
> 9sWAd10koNsZkG72nSoXnjFdXKUsXhGFK6k%3d
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"