[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-xsm testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 66a9274cc3435117783cd3f07b238309d7f9c6de Bug not present: 391266f0120c92ce8eb5bdb4a41bd314daaf6070 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/127868/ commit 66a9274cc3435117783cd3f07b238309d7f9c6de Author: Roger Pau Monné Date: Fri Sep 7 11:08:00 2018 +0200 iommu: make iommu_inclusive_mapping a suboption of dom0-iommu Introduce a new dom0-iommu=map-inclusive generic option that supersedes iommu_inclusive_mapping. The previous behavior is preserved and the option should only be enabled by default on Intel hardware. Signed-off-by: Roger Pau Monné Reviewed-by: Paul Durrant Reviewed-by: Jan Beulich Reviewed-by: Kevin Tian Acked-by: Julien Grall Acked-by: Suravee Suthikulpanit For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-xsm.xen-boot --summary-out=tmp/127868.bisection-summary --basis-template=127541 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-xsm xen-boot Searching for failure / basis pass: 127595 fail [host=elbling0] / 127541 [host=fiano1] 127520 [host=debina1] 127504 [host=albana1] 127489 [host=debina0] 127429 [host=pinot1] 127407 [host=baroque1] 127369 [host=joubertin0] 127350 [host=rimava1] 127301 [host=huxelrebe1] 127280 [host=pinot0] 127266 [host=chardonnay0] 127232 [host=italia0] 127123 [host=elbling1] 127070 ok. Failure / basis pass flights: 127595 / 127070 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 d7c60727a3f26b7fda49c8de188dd1cec021d23a Basis pass f4c88459f7c9320f587b839c3d24a2a9dc18a8a0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 f04955e18502035121776f6e09d83ae5a36c773c Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#f4c88459f7c9320f587b839c3d24a2a9dc18a8a0-7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f04955e18502035121776f6e09d83ae5a36c773c-d7c60727a3f26b7fda49c8de188dd1cec021d23a Loaded 2001 nodes in revision graph Searching for test results: 127070 pass f4c88459f7c9320f587b839c3d24a2a9dc18a8a0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 f04955e18502035121776f6e09d83ae5a36c773c 127012 [host=debina1] 127123 [host=elbling1] 127232 [host=italia0] 127266 [host=chardonnay0] 127280 [host=pinot0] 127301 [host=huxelrebe1] 127350 [host=rimava1] 127369 [host=joubertin0] 127407 [host=baroque1] 127429 [host=pinot1] 127489 [host=debina0] 127541 [host=fiano1] 127504 [host=albana1] 127520 [host=debina1] 127595 fail 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 d7c60727a3f26b7fda49c8de188dd1cec021d23a 127853 fail 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 7f855b514146478dfdd1f796ed5578a138164d11 127855 fail 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 66a9274cc3435117783cd3f07b238309d7f9c6de 127836 pass
Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters
On 20/09/18 18:06, Wei Liu wrote: > On Wed, Sep 19, 2018 at 07:58:50PM +0200, Juergen Gross wrote: >> >> Did you look into the patches, especially patch 10? The parameters set >> are all stored in domain config via libxl__arch_domain_save_config(). > > No, I didn't. > > I think the general idea of what you do in patch 10 should work. However > I want to comment on the implementation. > > It appears that the implementation in patch 10 concatenates the new > settings to the old ones. It is not very nice imo. > > If for the life time of the domain you set X times the same parameter > you get a string of foo=bar1 foo=bar2 in the saved config file. > > There is probably a simple solution: make the parameter list in IDL a > key value list. You then update the list accordingly. The problem with that approach are parameters with sub-parameters: par=sub1=no,sub2=yes par=sub2=yes would remove the sub1=no setting. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 127828: regressions - FAIL
flight 127828 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/127828/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 212df3f9573f7284d361f855bb6e476e5a0259e6 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 107 days Failing since123840 2018-06-06 04:19:28 Z 106 days 87 attempts Testing same since 127828 2018-09-19 22:34:42 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Dan Kenigsberg Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Fabiano Fidêncio Farhan Ali Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Lin Ma Lubomir Rintel Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Roman Bolshakov Shi Lei Shi Lei Shichangkuo Shivaprasad G Bhat Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský Vitaly Kuznetsov w00251574 Wang Huaqiang Weilun Zhu xinhua.Cao jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked
Re: [Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
On 2018/9/20 22:43, Stephen Hemminger wrote:
> On Thu, 20 Sep 2018 20:33:01 +0800
> YueHaibing wrote:
>
>> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
>> which is a typedef for an enum type, so make sure the implementation in
>> this driver has returns 'netdev_tx_t' value, and change the function
>> return type to netdev_tx_t.
>>
>> Found by coccinelle.
>>
>> Signed-off-by: YueHaibing
>> ---
>> drivers/net/hyperv/netvsc_drv.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/hyperv/netvsc_drv.c
>> b/drivers/net/hyperv/netvsc_drv.c
>> index 3af6d8d..056c472 100644
>> --- a/drivers/net/hyperv/netvsc_drv.c
>> +++ b/drivers/net/hyperv/netvsc_drv.c
>> @@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct
>> net_device *vf_netdev,
>> return rc;
>> }
>>
>> -static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
>> +static netdev_tx_t
>> +netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
>> {
>> struct net_device_context *net_device_ctx = netdev_priv(net);
>> struct hv_netvsc_packet *packet = NULL;
>> @@ -528,8 +529,11 @@ static int netvsc_start_xmit(struct sk_buff *skb,
>> struct net_device *net)
>> */
>> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
>> if (vf_netdev && netif_running(vf_netdev) &&
>> -!netpoll_tx_running(net))
>> -return netvsc_vf_xmit(net, vf_netdev, skb);
>> +!netpoll_tx_running(net)) {
>> +ret = netvsc_vf_xmit(net, vf_netdev, skb);
>> +if (ret)
>> +return NETDEV_TX_BUSY;
>> +}
>
> Sorry, the new code is wrong. It will fall through if ret == 0 (NETDEV_TX_OK)
> Please review and test your patches.
I'm sorry for this, will correct it as Haiyang's suggestion.
>
> .
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
On 2018/9/20 22:50, Haiyang Zhang wrote:
>
>
>> -Original Message-
>> From: Stephen Hemminger
>> Sent: Thursday, September 20, 2018 10:44 AM
>> To: YueHaibing
>> Cc: da...@davemloft.net; dmitry.tarnya...@lockless.no;
>> w...@grandegger.com; m...@pengutronix.de; michal.si...@xilinx.com;
>> hswee...@visionengravers.com; madalin.bu...@nxp.com;
>> pantelis.anton...@gmail.com; claudiu.man...@nxp.com; leoyang...@nxp.com;
>> li...@armlinux.org.uk; sa...@sammy.net; r...@linux-mips.org;
>> n...@fluxnic.net; steve.glendinn...@shawell.net; f.faine...@gmail.com;
>> grygorii.stras...@ti.com; w-kw...@ti.com; m-kariche...@ti.com;
>> t.sai...@alumni.ethz.ch; jreu...@yaina.de; KY Srinivasan
>> ;
>> Haiyang Zhang ; wei.l...@citrix.com;
>> paul.durr...@citrix.com; arvid.bro...@alten.se; pshe...@ovn.org;
>> d...@openvswitch.org; linux-m...@linux-mips.org; xen-
>> de...@lists.xenproject.org; net...@vger.kernel.org;
>> linux-...@vger.kernel.org;
>> linux-ker...@vger.kernel.org; linux-...@vger.kernel.org;
>> de...@linuxdriverproject.org; linux-h...@vger.kernel.org; linux-
>> o...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-arm-
>> ker...@lists.infradead.org
>> Subject: Re: [PATCH net-next 17/22] hv_netvsc: fix return type of
>> ndo_start_xmit function
>>
>> On Thu, 20 Sep 2018 20:33:01 +0800
>> YueHaibing wrote:
>>> int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
>>> */
>>> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
>>> if (vf_netdev && netif_running(vf_netdev) &&
>>> - !netpoll_tx_running(net))
>>> - return netvsc_vf_xmit(net, vf_netdev, skb);
>>> + !netpoll_tx_running(net)) {
>>> + ret = netvsc_vf_xmit(net, vf_netdev, skb);
>>> + if (ret)
>>> + return NETDEV_TX_BUSY;
>>> + }
>>
>> Sorry, the new code is wrong. It will fall through if ret == 0 (NETDEV_TX_OK)
>> Please review and test your patches.
>
> Plus consideration of -- For error case, please just return NETDEV_TX_OK. We
> are not sure if the error can go away after retrying, returning
> NETDEV_TX_BUSY
> may cause infinite retry from the upper layer.
>
> So, let's just always return NETDEV_TX_OK like this:
> netvsc_vf_xmit(net, vf_netdev, skb);
> return NETDEV_TX_OK;
Thank you for review.
Will do that in v2.
>
> Thanks,
> - Haiyang
>
> .
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
On 2018/9/20 23:50, David Miller wrote: > From: YueHaibing > Date: Thu, 20 Sep 2018 20:32:44 +0800 > >> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', >> which is a typedef for an enum type, so make sure the implementation in >> this driver has returns 'netdev_tx_t' value, and change the function >> return type to netdev_tx_t. > > I would advise you not to send so many of these changes as a group. > > If one of the patches needs feedback addressed, which is already the > case, you will have to resubmit the entire series all over again with > the fixes. > Yes, I will send it separately after test and review again. Thank you for your advice. > . > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/7] vtd: change lookup_page failure semantics
> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Thursday, September 20, 2018 10:12 PM > > Commit 43d1622b "vtd: add lookup_page method to iommu_ops" added a > lookup method in to the VT-d IOMMU implementation. In some cases (such > as > when shared EPT is in operation) that function simply passes back an > identity MFN (i.e. an MFN with the same value as the DFN that was passed > in), but this doesn't actually make a lot of sense. If, for instance, > shared EPT is used then really the function should be doing a P2M lookup > since DFN space will be identical to GFN space. > > In practice there are no current callers of the lookup_page method and, > when PV-IOMMU support is added, the method will not be called if either > shared EPT is in operation or iommu_passthrough is set, so this patch > simply fails the method with -EOPNOTSUPP in those cases. > > Signed-off-by: Paul Durrant Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 127793: regressions - FAIL
flight 127793 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/127793/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw
[Xen-devel] [xen-4.6-testing baseline-only test] 75257: trouble: blocked/broken
This run is configured for baseline tests only. flight 75257 xen-4.6-testing real [real] http://osstest.xensource.com/osstest/logs/75257/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken build-i386-prev broken build-armhf 4 host-install(4) broken REGR. vs. 75085 build-armhf-pvops 4 host-install(4) broken REGR. vs. 75085 build-amd64-prev 4 host-install(4) broken REGR. vs. 75085 build-i3864 host-install(4) broken REGR. vs. 75085 build-amd64 4 host-install(4) broken REGR. vs. 75085 build-amd64-pvops 4 host-install(4) broken REGR. vs. 75085 build-amd64-xsm 4 host-install(4) broken REGR. vs. 75085 build-i386-prev 4 host-install(4) broken REGR. vs. 75085 build-i386-pvops 4 host-install(4) broken REGR. vs. 75085 build-i386-xsm4 host-install(4) broken REGR. vs. 75085 build-amd64-xtf 4 host-install(4) broken REGR. vs. 75085 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-41 build-check(1) blocked
Re: [Xen-devel] tools/fuzz fails due build, osstest did not notice
On Tue, Sep 4, 2018 at 2:07 AM Jan Beulich wrote:
>
> >>> On 04.09.18 at 09:32, wrote:
> > Am Mon, 03 Sep 2018 06:35:42 -0600
> > schrieb "Jan Beulich" :
> >
> >> what is the actual problem? The mere
> >> listing of compiler flags passed does not make clear to me where the clash
> >> is, or how it would surface.
> >
> > As I noticed just now, it fails to build only in Tumbleweed. So in this
> > specific case osstest would have caught it only in a few years from now.
> >
> > [ 38s] make -C x86_instruction_emulator install
> > [ 38s] make[6]: Entering directory
> > '/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator'
> > [ 38s] [ -L x86-emulate.h ] || ln -sf
> > /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> > /fuzz/x86_instruction_emulator/../../../tools/tests/x86_emulator/x86-emulate.h
> > [ 38s] [ -L x86_emulate ] || ln -sf
> > /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> > /fuzz/x86_instruction_emulator/../../../xen/arch/x86/x86_emulate
> > [ 38s] /usr/bin/gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
> > -Wstrict-prototypes -Wdeclaration-after-statement
> > -Wno-unused-but-set-variable
> > -Wno-unused-local-typedefs -O0 -fno-omit-frame-pointer
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > .fuzz-emul.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -Wall
> > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
> > -fasynchronous-unwind-tables -fstack-clash-protection
> > -I/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator/../../../tools/include -D__XEN_TOOLS__ -I.
> > -c -o
> > fuzz-emul.o fuzz-emul.c
> > [ 38s] In file included from /usr/include/features.h:428,
> > [ 38s] from /usr/include/assert.h:35,
> > [ 38s] from fuzz-emul.c:1:
> > [ 38s] fuzz-emul.c: In function 'input_read':
> > [ 38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed
> > in call to always_inline 'memcpy': target specific option mismatch
> > [ 38s] __NTH (memcpy (void *__restrict __dest, const void *__restrict
> > __src,
> > [ 38s] ^
> > [ 38s] fuzz-emul.c:67:5: note: called from here
> > [ 38s] memcpy(dst, >corpus->data[s->data_index], size);
> > [ 38s] ^~
> > [ 38s] In file included from /usr/include/features.h:428,
> > [ 38s] from /usr/include/assert.h:35,
> > [ 38s] from fuzz-emul.c:1:
> > [ 38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed
> > in call to always_inline 'memcpy': target specific option mismatch
> > [ 38s] __NTH (memcpy (void *__restrict __dest, const void *__restrict
> > __src,
> > [ 38s] ^
> > [ 38s] fuzz-emul.c:67:5: note: called from here
> > [ 38s] memcpy(dst, >corpus->data[s->data_index], size);
> > [ 38s] ^~
> > [ 38s] make[6]: ***
> > [/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator/../../../tools/Rules.mk:225: fuzz-emul.o]
> > Error 1
> >
> > Appending -U_FORTIFY_SOURCE in tools/fuzz fixes it. Not sure why fuzz is
> > different from the rest of tools.
>
> No idea here either, for the moment, even after looking at gcc's
> ix86_can_inline_p() (which apparently is the function triggering the
> diagnostic).
I've just encountered this problem, building with the master branch of
OpenEmbedded and Yocto's poky, with compiler flags that include
_FORTIFY_SOURCE=2 -msse3
with gcc 8.2.0.
Xen's x86_emulator header file does:
#pragma GCC target("no-sse")
The pragma was introduced in Xen commit 79136f26, to prevent the compiler from
using registers otherwise used by inline memset and memcpy.
Setting _FORTIFY_SOURCE causes the use of always_inline variants of memset and
memcpy which use those instructions, which is now causing the inline to fail.
The behaviour is described in the GCC bugzilla here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991
{quote}
cat fuzz-emul.i
__attribute__((__always_inline__)) a() {}
#pragma GCC target "no-sse"
b() { a(); }
Where 'a' is 'memcpy' and 'b' is a function in xen.
Can you Honza also take a look r251333 where we started to reject such code?
{quote}
links to this GCC change:
https://gcc.gnu.org/viewcvs/gcc?view=revision=251333
Would the below Xen patch, which adds undefs for _FORTIFY_SOURCE just for the
two binaries which are affected be acceptable? It allows for use of
_FORTIFY_SOURCE with the rest of the build.
Christopher
diff --git a/tools/tests/x86_emulator/Makefile
b/tools/tests/x86_emulator/Makefile
index dec81c3..f7b9e58 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -133,7 +133,7 @@
Re: [Xen-devel] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
On 09/20/2018 07:32 AM, YueHaibing wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > May be I missed smth, but it's acceptable to report standard error codes from .xmit() callback as per dev_xmit_complete(). -- regards, -grygorii ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen: issue warning message when out of grant maptrack entries
On 9/19/18 9:42 AM, Juergen Gross wrote: > When a driver domain (e.g. dom0) is running out of maptrack entries it > can't map any more foreign domain pages. Instead of silently stalling > the affected domUs issue a rate limited warning in this case in order > to make it easier to detect that situation. > > Signed-off-by: Juergen Gross > Applied to for-linus-4.19d. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code
On 7/13/18 4:41 AM, Juergen Gross wrote: > On 12/07/18 19:27, Boris Ostrovsky wrote: >> Otherwise we may leak kernel stack for events that sample user >> registers. >> >> Reported-by: Mark Rutland >> Signed-off-by: Boris Ostrovsky >> Cc: sta...@vger.kernel.org > Reviewed-by: Juergen Gross > Belatedly, applied to for-linus-4.19d -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] libxl: made vm mac address assignment deterministic
On Wed, Sep 12, 2018 at 05:40:37PM +, Joshua Perrett wrote:
[...]
> +int libxl__get_host_mac(libxl__gc *gc, unsigned char *buf)
> +{
> +int rc = ERROR_FAIL;
> +
> +struct ifaddrs *iface_list;
> +uint8_t largest[6] = {0};
> +
> +if (getifaddrs(_list) == 0) {
> +for (struct ifaddrs *iface = iface_list;
> +iface != NULL; iface = iface->ifa_next) {
> +if (iface->ifa_addr && iface->ifa_addr->sa_family == AF_PACKET) {
> +struct sockaddr_ll *s = (struct sockaddr_ll
> *)iface->ifa_addr;
> +if (s->sll_halen == 6) {
> +if (memcmp(s->sll_addr, largest, s->sll_halen) > 0) {
> +memcpy(buf, s->sll_addr, s->sll_halen);
> +memcpy(largest, s->sll_addr, s->sll_halen);
> +rc = 0;
Sorry I didn't participate in the conversation IRL.
What is the resolution here?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] Created tools/shared directory containing MD5 files
On Wed, Sep 12, 2018 at 05:40:36PM +, Joshua Perrett wrote: > MD5 code is originally from the public domain (written by Colin Plumb in > 1993), files taken from xen/tools/blktap2/drivers/. They have been > modified slightly (useful functions made public). > > Signed-off-by: Joshua perrett > --- > tools/Makefile| 1 + > tools/Rules.mk| 1 + > tools/shared/Makefile | 21 > tools/shared/md5.c| 266 > ++ > tools/shared/md5.h| 26 + > 5 files changed, 315 insertions(+) > create mode 100644 tools/shared/Makefile > create mode 100644 tools/shared/md5.c > create mode 100644 tools/shared/md5.h > > diff --git a/tools/Makefile b/tools/Makefile > index 67977ad850..34ec41790d 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -24,6 +24,7 @@ SUBDIRS-$(CONFIG_BLKTAP2) += blktap2 > SUBDIRS-$(CONFIG_NetBSD) += xenbackendd > SUBDIRS-y += libfsimage > SUBDIRS-$(CONFIG_Linux) += libvchan > +SUBDIRS-y += shared I'm afraid building this in the shared directory is not quite right. You will need to use vpath in libxl/Makefile to add the shared/ directory to libxl. See https://www.gnu.org/software/make/manual/html_node/General-Search.html and libxc/Makefile for example. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] amd-iommu: add lookup_page method to iommu_ops
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Jan Beulich > Sent: 20 September 2018 16:04 > To: Paul Durrant > Cc: Andrew Cooper ; Brian Woods > ; Wei Liu ; Suravee > Suthikulpanit ; xen-devel de...@lists.xenproject.org> > Subject: Re: [Xen-devel] [PATCH 7/7] amd-iommu: add lookup_page method to > iommu_ops > > >>> On 20.09.18 at 16:11, wrote: > > This patch adds a new method to the AMD IOMMU implementation to find the > > MFN currently mapped by the specified DFN. This is analogous to the > > method added for VT-d IOMMU by commit 43d1622b. > > Please don't provide commit IDs from (presumably) your private repo, > the more without a title quoted next to it. At least patches 1 and 6 > have the same issue. OK... sorry getting ahead of myself. Need to wait for the pre-req series to go in. Paul > > Jan > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PXE boot with e1000 using OVMF
On Thu, Sep 20, 2018 at 12:33:42PM +0100, Anthony PERARD wrote: > On Wed, Sep 19, 2018 at 11:04:22AM -0600, Tamas K Lengyel wrote: > > On Wed, Sep 19, 2018 at 10:36 AM Wei Liu wrote: > > > > > > On Wed, Sep 12, 2018 at 11:54:02AM -0600, Tamas K Lengyel wrote: > > > > HI all, > > > > I'm experimenting with OVMF and I checked to see if OVMF can do PXE > > > > boot out-of-the box with a e1000 emulated network interface and was > > > > surprised to find that it does not. After reading some of the prior > > > > discussions on the topic (https://lists.gt.net/xen/devel/382432 and > > > > https://lists.xenproject.org/archives/html/xen-users/2015-09/msg00059.html) > > > > I was able to get the menu options to show up by copying efi-e1000.rom > > > > that gets installed by Xen's QEMU build into the disk of the VM and > > > > then loading with loadpcirom manually in the EFI shell. From the prior > > > > discussions it sounds to me like this option rom should have been > > > > automatically served by QEMU to OVMF when the VM started as an > > > > OptionROM. So is this a bug or what's missing? > > > > > > Doesn't QEMU load the option ROM automatically when you specify e1000? > > > > > > I _think_ it loads option ROM automatically because I have seen complain > > > that if you configure too many emulated NICs the guest runs out of > > > memory. > > > > I compiled QEMU with DEBUG_PCI enabled in hw/pci/pci.c and then the > > log shows efi-e1000.rom being loaded. However, AFAICT since PCI > > enumeration is disabled in OVMF when running under Xen (I'm not > > exactly sure why) the option rom never gets executed as it only gets > > It's because hvmloader (which is runned before OVMF start) takes care of > enumerating the PCI bus. OVMF only has to read the information: > via OvmfPkg/Library/PciHostBridgeLib/XenSupport.c Indeed. > > I can try to find out what's needed in order to load an option rom, or > ask on edk2-devel. Thank you! Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters
On Wed, Sep 19, 2018 at 07:58:50PM +0200, Juergen Gross wrote: > > Did you look into the patches, especially patch 10? The parameters set > are all stored in domain config via libxl__arch_domain_save_config(). No, I didn't. I think the general idea of what you do in patch 10 should work. However I want to comment on the implementation. It appears that the implementation in patch 10 concatenates the new settings to the old ones. It is not very nice imo. If for the life time of the domain you set X times the same parameter you get a string of foo=bar1 foo=bar2 in the saved config file. There is probably a simple solution: make the parameter list in IDL a key value list. You then update the list accordingly. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] null scheduler bug
Hey,
Sorry for not having followed up. I was (and still am) planning to, but
am also a bit busy.
On Thu, 2018-09-20 at 15:04 +0200, Milan Boberic wrote:
> I ran some more tests and managed to successfully create and destroy
> domU as many times as I want, without any delay between destroy and
> create.
> I added:
> printk("End of a domain_destroy function");
> in domain_destroy function and
> printk("End of a complete_domain_destroy function"); in
> complete_domain_destroy function, at the end of the functions.
> Those functions are in domain.c file.
>
Right. This is exactly the kind of debug patch I wanted to
suggest/send. It is, in fact, what was being use to diagnose/fix the
RCU issue, when it first came up, as you may have seen.
> Now, after every xl create it prints:
>
> root@uz3eg-iocc-2018-2:~# xl create bm1.cfg
> Parsing config from bm1.cfg
> <3>memory_map:add: dom2 gfn=ff0a0 mfn=ff0a0 nr=1
>
Mmm... So, you added a printk() (or, actually, two of them) in the
domain destruction path, and are seeing (different) things being
printed during domain creation? How nice! :-D
I'm not sure how that happens, and whether/how this new output relates
to the problem. However, what about the printk() you added? Do you see
their output? It may be visible only on the console and/or in `xl
dmesg'.
While there, if you can, I'd add timestamsp, e.g.:
printk("t=%"PRI_stime":End of a domain_destroy function", NOW());
printk("t=%"PRI_stime":End of a complete_domain_destroy function", NOW());
and check what the outpur looks like both under credit or credit2, and
under null.
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/4] x86/HVM: implement memory read caching
On Thu, Sep 20, 2018 at 12:39:59AM -0600, Jan Beulich wrote: > >>> On 19.09.18 at 17:57, wrote: > > On Tue, Sep 11, 2018 at 07:15:19AM -0600, Jan Beulich wrote: > >> Emulation requiring device model assistance uses a form of instruction > >> re-execution, assuming that the second (and any further) pass takes > >> exactly the same path. This is a valid assumption as far use of CPU > >> registers goes (as those can't change without any other instruction > >> executing in between), but is wrong for memory accesses. In particular > >> it has been observed that Windows might page out buffers underneath an > >> instruction currently under emulation (hitting between two passes). If > >> the first pass translated a linear address successfully, any subsequent > >> pass needs to do so too, yielding the exact same translation. > > > > Not sure I follow. If the buffers are paged out between two passes, how > > would caching the translation help? Yes you get the same translation > > result but the content of the address pointed to by the translation > > result could be different, right? > > If we accessed that memory, yes. But the whole point here is to avoid > memory accesses during retry processing, when the same access has > already occurred during an earlier round. As noted on another sub- > thread, the term "cache" here may be a little misleading, as it's not > there to improve performance (this, if so, would just be a desirable > side effect), but to guarantee correctness. I've chosen this naming for > the lack of a better alternative. > > So during replay/retry, inductively by all previously performed > accesses coming from this cache, the result is going to be the same > as that of the previous run. It's just that, for now, we use _this_ > cache only for page table accesses. But don't forget that there is > at least one other cache in place (struct hvm_vcpu_io's > mmio_cache[]). > > For the paged-out scenario this means that despite the leaf page > table entry having changed to some non-present one between the > original run through emulation code and the replay/retry after > having received qemu's reply, since that PTE won't be read again > the original translation will be (re)used. Right. I got your idea up to this point. I would appreciate if you can put the following paragraphs into commit message. > > For the actual data page in this scenario, while you're right that its > contents may have changed, there are a couple of aspects to take > into consideration: > - We must be talking about an insn accessing two locations (two > memory ones, one of which is MMIO, or a memory and an I/O one). > - If the non I/O / MMIO side is being read, the re-read (if it occurs > at all) is having its result discarded, by taking the shortcut through > the first switch()'s STATE_IORESP_READY case in hvmemul_do_io(). > Note how, among all the re-issue sanity checks there, we avoid > comparing the actual data. > - If the non I/O / MMIO side is being written, it is the OSes > responsibility to avoid actually moving page contents to disk while > there might still be a write access in flight - this is no different in > behavior from bare hardware. > - Read-modify-write accesses are, as always, complicated, and > while we deal with them better nowadays than we did in the past, > we're still not quite there to guarantee hardware like behavior in > all cases anyway. Nothing is getting worse by the changes made > here, afaict. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] iommu: setup inclusive mappings before enabling iommu
Hi Roger,
On 09/14/2018 02:58 PM, Roger Pau Monne wrote:
Or else it can lead to freezes when enabling the iommu on certain
Intel hardware:
[...]
(XEN) ELF: addresses:
(XEN) virt_base= 0x8000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0x8000
(XEN) virt_kstart = 0x8100
(XEN) virt_kend= 0x82953000
(XEN) virt_entry = 0x8274e180
(XEN) p2m_base = 0x80
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x295300
This restores the behavior before commit 66a9274cc3435 that changed
the order and enabled the iommu without having the inclusive mappings
setup.
Note that on AMD hardware the order is also changed to add inclusive
mappings before adding any devices.
Reported-by: Dario Faggioli
Signed-off-by: Roger Pau Monné
Acked-by: Julien Grall
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Kevin Tian
Cc: Dario Faggioli
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 ++
xen/drivers/passthrough/arm/smmu.c | 2 ++
xen/drivers/passthrough/iommu.c | 10 --
xen/drivers/passthrough/vtd/iommu.c | 2 ++
xen/drivers/passthrough/x86/iommu.c | 8
5 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 330f9ce386..4a633ca940 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -300,6 +300,8 @@ static void __hwdom_init amd_iommu_hwdom_init(struct domain
*d)
IOMMU_MMIO_REGION_LENGTH - 1)) )
BUG();
+/* Make sure workarounds are applied (if needed) before adding devices. */
+arch_iommu_hwdom_init(d);
setup_hwdom_pci_devices(d, amd_iommu_add_device);
}
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 43ece42a50..8f91807b1b 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2736,6 +2736,8 @@ static void __hwdom_init arm_smmu_iommu_hwdom_init(struct
domain *d)
printk(XENLOG_WARNING
"map-reserved dom0-iommu option is not supported on ARM\n");
iommu_hwdom_reserved = 0;
+
+ arch_iommu_hwdom_init(d);
}
static void arm_smmu_iommu_domain_teardown(struct domain *d)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index ee3f523fdf..ae6cf2f0ff 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -238,16 +238,6 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
}
hd->platform_ops->hwdom_init(d);
-
-ASSERT(iommu_hwdom_inclusive != -1 && iommu_hwdom_inclusive != -1);
-if ( iommu_hwdom_inclusive && !is_pv_domain(d) )
-{
-printk(XENLOG_WARNING
- "IOMMU inclusive mappings are only supported on PV Dom0\n");
-iommu_hwdom_inclusive = 0;
-}
-
-arch_iommu_hwdom_init(d);
}
void iommu_teardown(struct domain *d)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index adc70f205a..bb422ec58c 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1313,6 +1313,8 @@ static void __hwdom_init intel_iommu_hwdom_init(struct
domain *d)
setup_hwdom_pci_devices(d, setup_hwdom_device);
setup_hwdom_rmrr(d);
+/* Make sure workarounds are applied before enabling the IOMMU(s). */
+arch_iommu_hwdom_init(d);
if ( iommu_flush_all() )
printk(XENLOG_WARNING VTDPREFIX
diff --git a/xen/drivers/passthrough/x86/iommu.c
b/xen/drivers/passthrough/x86/iommu.c
index 47a078272a..b7c8b5be41 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -210,6 +210,14 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
BUG_ON(!is_hardware_domain(d));
+ASSERT(iommu_hwdom_inclusive != -1 && iommu_hwdom_inclusive != -1);
+if ( iommu_hwdom_inclusive && !is_pv_domain(d) )
+{
+printk(XENLOG_WARNING
+ "IOMMU inclusive mappings are only supported on PV Dom0\n");
+iommu_hwdom_inclusive = 0;
+}
+
if ( iommu_hwdom_passthrough )
return;
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
> -Original Message-
> From: YueHaibing
> Sent: Thursday, September 20, 2018 8:33 AM
> To: da...@davemloft.net; dmitry.tarnya...@lockless.no;
> w...@grandegger.com; m...@pengutronix.de; michal.si...@xilinx.com;
> hswee...@visionengravers.com; madalin.bu...@nxp.com;
> pantelis.anton...@gmail.com; claudiu.man...@nxp.com; leoyang...@nxp.com;
> li...@armlinux.org.uk; sa...@sammy.net; r...@linux-mips.org;
> n...@fluxnic.net; steve.glendinn...@shawell.net; f.faine...@gmail.com;
> grygorii.stras...@ti.com; w-kw...@ti.com; m-kariche...@ti.com;
> t.sai...@alumni.ethz.ch; jreu...@yaina.de; KY Srinivasan ;
> Haiyang Zhang ; wei.l...@citrix.com;
> paul.durr...@citrix.com; arvid.bro...@alten.se; pshe...@ovn.org
> Cc: linux-ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; linux-m...@linux-mips.org; linux-o...@vger.kernel.org;
> linux-h...@vger.kernel.org; de...@linuxdriverproject.org; linux-
> u...@vger.kernel.org; xen-devel@lists.xenproject.org; d...@openvswitch.org;
> YueHaibing
> Subject: [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit
> function
>
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is
> a typedef for an enum type, so make sure the implementation in this driver has
> returns 'netdev_tx_t' value, and change the function return type to
> netdev_tx_t.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
> ---
> drivers/net/hyperv/netvsc_drv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 3af6d8d..056c472 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct
> net_device *vf_netdev,
> return rc;
> }
>
> -static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> +static netdev_tx_t
> +netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_netvsc_packet *packet = NULL; @@ -528,8 +529,11 @@
> static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
>*/
> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
> if (vf_netdev && netif_running(vf_netdev) &&
> - !netpoll_tx_running(net))
> - return netvsc_vf_xmit(net, vf_netdev, skb);
> + !netpoll_tx_running(net)) {
> + ret = netvsc_vf_xmit(net, vf_netdev, skb);
> + if (ret)
> + return NETDEV_TX_BUSY;
For error case, please just return NETDEV_TX_OK. We are not sure if the
error can go away after retrying, returning NETDEV_TX_BUSY may cause
infinite retry from the upper layer.
Thanks,
- Haiyang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, September 20, 2018 10:44 AM
> To: YueHaibing
> Cc: da...@davemloft.net; dmitry.tarnya...@lockless.no;
> w...@grandegger.com; m...@pengutronix.de; michal.si...@xilinx.com;
> hswee...@visionengravers.com; madalin.bu...@nxp.com;
> pantelis.anton...@gmail.com; claudiu.man...@nxp.com; leoyang...@nxp.com;
> li...@armlinux.org.uk; sa...@sammy.net; r...@linux-mips.org;
> n...@fluxnic.net; steve.glendinn...@shawell.net; f.faine...@gmail.com;
> grygorii.stras...@ti.com; w-kw...@ti.com; m-kariche...@ti.com;
> t.sai...@alumni.ethz.ch; jreu...@yaina.de; KY Srinivasan ;
> Haiyang Zhang ; wei.l...@citrix.com;
> paul.durr...@citrix.com; arvid.bro...@alten.se; pshe...@ovn.org;
> d...@openvswitch.org; linux-m...@linux-mips.org; xen-
> de...@lists.xenproject.org; net...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-...@vger.kernel.org;
> de...@linuxdriverproject.org; linux-h...@vger.kernel.org; linux-
> o...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH net-next 17/22] hv_netvsc: fix return type of
> ndo_start_xmit function
>
> On Thu, 20 Sep 2018 20:33:01 +0800
> YueHaibing wrote:
> > int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> > */
> > vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
> > if (vf_netdev && netif_running(vf_netdev) &&
> > - !netpoll_tx_running(net))
> > - return netvsc_vf_xmit(net, vf_netdev, skb);
> > + !netpoll_tx_running(net)) {
> > + ret = netvsc_vf_xmit(net, vf_netdev, skb);
> > + if (ret)
> > + return NETDEV_TX_BUSY;
> > + }
>
> Sorry, the new code is wrong. It will fall through if ret == 0 (NETDEV_TX_OK)
> Please review and test your patches.
Plus consideration of -- For error case, please just return NETDEV_TX_OK. We
are not sure if the error can go away after retrying, returning NETDEV_TX_BUSY
may cause infinite retry from the upper layer.
So, let's just always return NETDEV_TX_OK like this:
netvsc_vf_xmit(net, vf_netdev, skb);
return NETDEV_TX_OK;
Thanks,
- Haiyang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit
On 9/20/18 2:34 PM, George Dunlap wrote:
>> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
>> +unsigned int altp2m_idx)
> This should clearly be in p2m.c, and...
>
>> +{
>> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>> +struct p2m_domain *ap2m = NULL;
>> +struct p2m_domain *p2m;
>> +mfn_t mfn;
>> +p2m_access_t a;
>> +p2m_type_t t;
>> +int rc;
>> +
>> +if ( !cpu_has_vmx_virt_exceptions )
>> +return -EOPNOTSUPP;
> We should avoid Intel-specific checks in common code.
>
> In fact, this is wrong, because you can choose to run a guest in shadow
> mode even on a system with virt exceptions -- in which case you'd
> trigger the ASSERT() in p2m-pt.c:p2m_pt_set_entry().
>
> Probably what should happen is that we should move the vmx check into
> p2m-ept.c:p2m_ept_set_entry(), and replace the ASSERT(sve = 0) in
> p2m-pt.c:p2m_pt_set_entry() with "if ( sve != 0 ) return -ENOTSUPP;".
>
> Although what should probably *really* happen is that
> `HVMOP_altp2m_vcpu_enable_notify` should fail with -EOPNOTSUPP instead
> of silently succeeding.
Do you mean HVMOP_altp2m_set_suppress_ve here, or am I misunderstanding
your comment? I'm happy to do the exact modifications you've requested
above but I'm afraid I don't follow the HVMOP_altp2m_vcpu_enable_notify
comment.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
From: YueHaibing Date: Thu, 20 Sep 2018 20:32:44 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. I would advise you not to send so many of these changes as a group. If one of the patches needs feedback addressed, which is already the case, you will have to resubmit the entire series all over again with the fixes. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Make XEN_BACKEND selectable by DomU
On Thu, Sep 20, 2018 at 10:54 AM Jan Beulich wrote: > > >>> On 20.09.18 at 16:32, wrote: > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -101,8 +101,7 @@ config XEN_DEV_EVTCHN > > > > config XEN_BACKEND > > bool "Backend driver support" > > - depends on XEN_DOM0 > > - default y > > + default y if XEN_DOM0 > > Why not the simpler "default XEN_DOM0"? I didn't realize you could do that. :) Yes, that's nicer. Thanks, Jason ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On Thu, Sep 20, 2018 at 3:55 PM Razvan Cojocaru wrote: > > On 9/20/18 5:42 PM, George Dunlap wrote: > > I do have a question about your proposed use case. You're running > > this in 'mixed' mode, right, and using the altp2m to hide a secure bit > > of code from the operating system? What's to stop a rogue operating > > system that doesn't want to be introspected from calling > > HVMOP_altp2m_vcpu_enable_notify with INVALID_GFN to disable this? > > Nothing, but we're not running this in mixed mode. :) > We're after 'external', for the very same reasons you've mentioned. > > Everything important is done in dom0-only. If there's something to be > done that the in-guest agent would like, it has to ask the introspection > agent in dom0 via VMCALL events. OK, got it, thanks. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 127804: all pass - PUSHED
flight 127804 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/127804/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd fb80e9f8be0c30110a80d98247b82f1d42dd909d baseline version: freebsd 6c2192b1ef8c50788c751f878552526800b1e319 Last test of basis 127721 2018-09-17 09:19:08 Z3 days Testing same since 127804 2018-09-19 09:19:29 Z1 days1 attempts People who touched revisions under test: ae bdrewery brd brooks davidcs emaste gjb jhb kib markj mjg np tuexen jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/freebsd.git 6c2192b1ef8..fb80e9f8be0 fb80e9f8be0c30110a80d98247b82f1d42dd909d -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-wheezy test] 75255: trouble: blocked/broken
flight 75255 distros-debian-wheezy real [real] http://osstest.xensource.com/osstest/logs/75255/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-i386-i386-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-wheezy-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-wheezy-netboot-pygrub 1 build-check(1) blocked n/a build-armhf 4 host-install(4) broken like 75212 build-armhf-pvops 4 host-install(4) broken like 75212 build-amd64-pvops 4 host-install(4) broken like 75212 build-i3864 host-install(4) broken like 75212 build-amd64 4 host-install(4) broken like 75212 build-i386-pvops 4 host-install(4) broken like 75212 baseline version: flight 75212 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked test-amd64-i386-i386-wheezy-netboot-pvgrub blocked test-amd64-i386-amd64-wheezy-netboot-pygrub blocked test-amd64-amd64-i386-wheezy-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] amd-iommu: add lookup_page method to iommu_ops
>>> On 20.09.18 at 16:11, wrote: > This patch adds a new method to the AMD IOMMU implementation to find the > MFN currently mapped by the specified DFN. This is analogous to the > method added for VT-d IOMMU by commit 43d1622b. Please don't provide commit IDs from (presumably) your private repo, the more without a title quoted next to it. At least patches 1 and 6 have the same issue. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On 9/20/18 5:42 PM, George Dunlap wrote: > I do have a question about your proposed use case. You're running > this in 'mixed' mode, right, and using the altp2m to hide a secure bit > of code from the operating system? What's to stop a rogue operating > system that doesn't want to be introspected from calling > HVMOP_altp2m_vcpu_enable_notify with INVALID_GFN to disable this? Nothing, but we're not running this in mixed mode. :) We're after 'external', for the very same reasons you've mentioned. Everything important is done in dom0-only. If there's something to be done that the in-guest agent would like, it has to ask the introspection agent in dom0 via VMCALL events. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Make XEN_BACKEND selectable by DomU
>>> On 20.09.18 at 16:32, wrote: > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -101,8 +101,7 @@ config XEN_DEV_EVTCHN > > config XEN_BACKEND > bool "Backend driver support" > - depends on XEN_DOM0 > - default y > + default y if XEN_DOM0 Why not the simpler "default XEN_DOM0"? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case
>>> On 20.09.18 at 16:13, wrote: > On 20/09/18 14:39, Jan Beulich wrote: > On 20.09.18 at 14:41, wrote: >>> On 13/09/18 11:12, Jan Beulich wrote: The function does two translations in one go for a single guest access. Any failure of the first translation step (guest linear -> guest physical), resulting in #PF, ought to take precedence over any failure of the second step (guest physical -> host physical). >>> Why? What is the basis of this presumption? >>> >>> As far as what real hardware does... >>> >>> This test sets up a ballooned page and a read-only page. I.e. a second >>> stage fault on the first part of a misaligned access, and a first stage >>> fault on the second part of the access. >>> >>> (d1) --- Xen Test Framework --- >>> (d1) Environment: HVM 64bit (Long mode 4 levels) >>> (d1) Test splitfault >>> (d1) About to read >>> (XEN) *** EPT qual 0181, gpa 0011cffc >>> (d1) Reading PTR: got >>> (d1) About to write >>> (XEN) *** EPT qual 0182, gpa 0011cffc >>> (d1) ** >>> (d1) PANIC: Unhandled exception at 0008:001047e0 >>> (d1) Vec 14 #PF[-d-sWP] %cr2 0011d000 >>> (d1) ** >>> >>> The second stage fault is recognised first, which is contrary to your >>> presumption, i.e. the code in its current form appears to be correct. >> But the guest doesn't know about 2nd stage translation. In the >> absence of it, the (1st stage / only) fault ought to occur before >> any bus level actions would be taken. > > You have not answered my question. > > Why? On what basis do you conclude that the behaviour you describe is > "correct", especially now given evidence to the contrary? As to the basis I'm taking: Without it spelled out anywhere, any sensible behavior can be considered "correct". But let's look at the steps unpatched code takes: hvm_translate_get_page() for the tail of the first page produces HVMTRANS_bad_gfn_to_mfn, so we bail from the loop, returning NULL. The caller takes this as an indication to write the range in pieces. Hence a write to the last bytes of the first page occurs (if it was MMIO instead of a ballooned page) before we raise #PF. Now let's look at patched code behavior: hvm_translate_get_page() for the tail of the first page produces HVMTRANS_bad_gfn_to_mfn again, but we continue the loop. hvm_translate_get_page() for the start of the second page produces HVMTRANS_bad_linear_to_gfn, so we raise #PF without first doing a partial write. I continue to think that this is the less surprising behavior. Without it being mandated that the partial write _has_ to occur, I'd much prefer this changed behavior, no matter how the specific piece of hardware behaves that you ran your test on. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
On Thu, 20 Sep 2018 20:33:01 +0800
YueHaibing wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
> ---
> drivers/net/hyperv/netvsc_drv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 3af6d8d..056c472 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct
> net_device *vf_netdev,
> return rc;
> }
>
> -static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> +static netdev_tx_t
> +netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_netvsc_packet *packet = NULL;
> @@ -528,8 +529,11 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
> net_device *net)
>*/
> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
> if (vf_netdev && netif_running(vf_netdev) &&
> - !netpoll_tx_running(net))
> - return netvsc_vf_xmit(net, vf_netdev, skb);
> + !netpoll_tx_running(net)) {
> + ret = netvsc_vf_xmit(net, vf_netdev, skb);
> + if (ret)
> + return NETDEV_TX_BUSY;
> + }
Sorry, the new code is wrong. It will fall through if ret == 0 (NETDEV_TX_OK)
Please review and test your patches.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On Tue, Sep 4, 2018 at 6:00 AM Adrian Pop wrote: > > In a classic HVI + Xen setup, the introspection engine would monitor > legacy guest page-tables by marking them read-only inside the EPT; this > way any modification explicitly made by the guest or implicitly made by > the CPU page walker would trigger an EPT violation, which would be > forwarded by Xen to the SVA and thus the HVI agent. The HVI agent would > analyse the modification, and act upon it - for example, a virtual page > may be remapped (its guest physical address changed inside the > page-table), in which case the introspection logic would update the > protection accordingly (remove EPT hook on the old gpa, and place a new > EPT hook on the new gpa). In other cases, the modification may be of no > interest to the introspection engine - for example, the accessed/dirty > bits may be cleared by the operating system or the accessed/dirty bits > may be set by the CPU page walker. > > In our tests we discovered that the vast majority of guest page-table > modifications fall in the second category (especially on Windows 10 RS4 > x64 - more than 95% of ALL the page-table modifications are irrelevant to > us) - they are of no interest to the introspection logic, but they > trigger a very costly EPT violation nonetheless. Therefore, we decided > to make use of the new #VE & VMFUNC features in recent Intel CPUs to > accelerate the guest page-tables monitoring in the following way: > > 1. Each monitored page-table would be flagged as being convertible >inside the EPT, thus enabling the CPU to deliver a virtualization >exception to he guest instead of generating a traditional EPT >violation. > 2. We inject a small filtering driver inside the protected guest VM, >which would intercept the virtualization exception in order to handle >guest page-table modifications. > 3. We create a dedicated EPT view (altp2m) for the in-guest agent, which >would isolate the agent from the rest of the operating system; the >agent will switch in and out of the protected EPT view via the VMFUNC >instruction placed inside a trampoline page, thus making the agent >immune to malicious code inside the guest. > > This way, all the page-table accesses would generate a > virtualization-exception inside the guest instead of a costly EPT > violation; the #VE agent would emulate and analyse the modification, and > decide whether it is relevant for the main introspection logic; if it is > relevant, it would do a VMCALL and notify the introspection engine > about the modification; otherwise, it would resume normal instruction > execution, thus avoiding a very costly VM exit. > > Signed-off-by: Adrian Pop I don't have any objections to the code; I think it can stay in the tree as far as I'm concerned. I do have a comment on the commit message, just for future reference at this point. It goes into a lot of detail about the architecture of what you're trying to accomplish, but not what this patch actually does. I think something like "Allow a dom0 agent to enable vcpu_notify on guest vcpus, to enable an out-of-guest introspection agent to insert an in-guest agent into a guest" would have been enough. I do have a question about your proposed use case. You're running this in 'mixed' mode, right, and using the altp2m to hide a secure bit of code from the operating system? What's to stop a rogue operating system that doesn't want to be introspected from calling HVMOP_altp2m_vcpu_enable_notify with INVALID_GFN to disable this? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] clean up physical merging helpers
On 9/20/18 12:29 AM, Christoph Hellwig wrote: > On Sat, Sep 15, 2018 at 08:47:13AM -0600, Jens Axboe wrote: this series moves various helpers related to merging based on physical addresses from the public headers into block/, moves the Xen special case from arch hooks into common code, cleans up the code a bit, and removes not nessecary includes from the block headers. >>> ---end quoted text--- >>> >> >> It's a good cleanup, I like it. Would prefer if the arm/xen folks could >> ack the first bits, > > Konread, can you look at the series (or delegate). > >> and 13/13 should probably just to in differently. > > I can't parse this setence. The irony is thick :-) Anyway, s/to/go for that sentence. I don't mind carrying it if Konrad is happy with it, but it could go in separately after this series is merged. -- Jens Axboe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.6-testing test] 127792: tolerable FAIL - PUSHED
flight 127792 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/127792/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 127746 pass in 127792 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 127746 pass in 127792 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 127746 pass in 127792 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 127746 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 127746 like 125934 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125934 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125934 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125934 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125934 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125934 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 125934 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125934 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125934 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125934 test-xtf-amd64-amd64-5 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 78 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-4 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-1 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-4 78 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-1 78 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 37 xtf/test-hvm32pae-memop-seg fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-2 78 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 78 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10
[Xen-devel] [PATCH] xen: Make XEN_BACKEND selectable by DomU
XEN_BACKEND doesn't actually depend on XEN_DOM0. DomUs can serve backends to other DomUs. One example is a service VM providing network backends. The original Kconfig defaulted Dom0 to y and it could be disabled. DomU could not select the option. With the new Kconfig, we default y for Dom0 and n for DomU. Either can then toggle the selection. Signed-off-by: Jason Andryuk --- OpenXT runs network backends in a network service DomU that shares out PCI NICs. drivers/xen/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b459edfacff3..af1bf99318c6 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -101,8 +101,7 @@ config XEN_DEV_EVTCHN config XEN_BACKEND bool "Backend driver support" - depends on XEN_DOM0 - default y + default y if XEN_DOM0 help Support for backend device drivers that provide I/O services to other virtual machines. -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86/hvm: Change return error for offline vcpus
On Thu, 2018-09-20 at 07:55 -0600, Jan Beulich wrote: > > > > On 20.09.18 at 14:54, wrote: > > > > --- a/xen/arch/x86/hvm/save.c > > +++ b/xen/arch/x86/hvm/save.c > > @@ -165,7 +165,7 @@ int hvm_save_one(struct domain *d, unsigned int > > typecode, unsigned int instance, > > if ( (rv = hvm_sr_handlers[typecode].save(v, )) != 0 ) > > printk(XENLOG_G_ERR "HVM%d save: failed to save type > > %"PRIu16" (%d)\n", > > d->domain_id, typecode, rv); > > -else if ( rv = -ENOENT, ctxt.cur >= sizeof(*desc) ) > > +else if ( rv = -ENODATA, ctxt.cur >= sizeof(*desc) ) > > I think this change of error code should once again only be done > for HVMSR_PER_VCPU kind records. For the others no data > appearing is _the_ indication of the instance not existing. > Ok, I will add a conditional for this inside the if() Thanks, Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case
On 20/09/18 14:39, Jan Beulich wrote: On 20.09.18 at 14:41, wrote: >> On 13/09/18 11:12, Jan Beulich wrote: >>> The function does two translations in one go for a single guest access. >>> Any failure of the first translation step (guest linear -> guest >>> physical), resulting in #PF, ought to take precedence over any failure >>> of the second step (guest physical -> host physical). >> Why? What is the basis of this presumption? >> >> As far as what real hardware does... >> >> This test sets up a ballooned page and a read-only page. I.e. a second >> stage fault on the first part of a misaligned access, and a first stage >> fault on the second part of the access. >> >> (d1) --- Xen Test Framework --- >> (d1) Environment: HVM 64bit (Long mode 4 levels) >> (d1) Test splitfault >> (d1) About to read >> (XEN) *** EPT qual 0181, gpa 0011cffc >> (d1) Reading PTR: got >> (d1) About to write >> (XEN) *** EPT qual 0182, gpa 0011cffc >> (d1) ** >> (d1) PANIC: Unhandled exception at 0008:001047e0 >> (d1) Vec 14 #PF[-d-sWP] %cr2 0011d000 >> (d1) ** >> >> The second stage fault is recognised first, which is contrary to your >> presumption, i.e. the code in its current form appears to be correct. > But the guest doesn't know about 2nd stage translation. In the > absence of it, the (1st stage / only) fault ought to occur before > any bus level actions would be taken. You have not answered my question. Why? On what basis do you conclude that the behaviour you describe is "correct", especially now given evidence to the contrary? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/7] amd-iommu: don't domain_crash() inside map/unmap_page()
Commit c210cafb "iommu: don't domain_crash() inside iommu_map/unmap_page()"
removed the implicit domain_crash() from the iommu_ops wrapper functions.
This patch does the same thing in the AMD IOMMU implementation. This is a
necessary pre-requisite for implementation of PV IOMMU.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index c89c54fdb6..8a10412a07 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -653,7 +653,6 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t
mfn,
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %"PRI_dfn"\n",
dfn_x(dfn));
-domain_crash(d);
return rc;
}
@@ -666,7 +665,6 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t
mfn,
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
dfn_x(dfn));
-domain_crash(d);
return -EFAULT;
}
}
@@ -676,7 +674,6 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t
mfn,
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %"PRI_dfn"\n",
dfn_x(dfn));
-domain_crash(d);
return -EFAULT;
}
@@ -711,7 +708,6 @@ int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t
mfn,
AMD_IOMMU_DEBUG("Merge iommu page failed at level %d, "
"dfn = %"PRI_dfn" mfn = %"PRI_mfn"\n",
merge_level, dfn_x(dfn), mfn_x(mfn));
-domain_crash(d);
return -EFAULT;
}
@@ -753,8 +749,6 @@ int amd_iommu_unmap_page(struct domain *d, dfn_t dfn)
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
dfn_x(dfn));
-if ( rc != -EADDRNOTAVAIL )
-domain_crash(d);
return rc;
}
}
@@ -764,7 +758,6 @@ int amd_iommu_unmap_page(struct domain *d, dfn_t dfn)
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %"PRI_dfn"\n",
dfn_x(dfn));
-domain_crash(d);
return -EFAULT;
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/7] amd-iommu: convert all bool_t to bool
Fix assignments to use 'false' rather than '0'.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index e4f22c9fc6..d7df8b9161 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -45,13 +45,13 @@ void clear_iommu_pte_present(unsigned long l1_mfn, unsigned
long dfn)
unmap_domain_page(table);
}
-static bool_t set_iommu_pde_present(uint32_t *pde, unsigned long next_mfn,
-unsigned int next_level,
-bool_t iw, bool_t ir)
+static bool set_iommu_pde_present(uint32_t *pde, unsigned long next_mfn,
+ unsigned int next_level,
+ bool iw, bool ir)
{
uint64_t addr_lo, addr_hi, maddr_old, maddr_next;
uint32_t entry;
-bool_t need_flush = 0;
+bool need_flush = false;
maddr_next = (uint64_t)next_mfn << PAGE_SHIFT;
@@ -104,13 +104,13 @@ static bool_t set_iommu_pde_present(uint32_t *pde,
unsigned long next_mfn,
return need_flush;
}
-static bool_t set_iommu_pte_present(unsigned long pt_mfn, unsigned long dfn,
-unsigned long next_mfn, int pde_level,
-bool_t iw, bool_t ir)
+static bool set_iommu_pte_present(unsigned long pt_mfn, unsigned long dfn,
+ unsigned long next_mfn, int pde_level,
+ bool iw, bool ir)
{
uint64_t *table;
uint32_t *pde;
-bool_t need_flush = 0;
+bool need_flush = false;
table = map_domain_page(_mfn(pt_mfn));
@@ -339,7 +339,7 @@ static int iommu_update_pde_count(struct domain *d,
unsigned long pt_mfn,
uint64_t *table, *pde, *ntable;
uint64_t ntable_maddr, mask;
struct domain_iommu *hd = dom_iommu(d);
-bool_t ok = 0;
+bool ok = false;
ASSERT( spin_is_locked(>arch.mapping_lock) && pt_mfn );
@@ -633,7 +633,7 @@ static int update_paging_mode(struct domain *d, unsigned
long dfn)
int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
unsigned int flags)
{
-bool_t need_flush = 0;
+bool need_flush = false;
struct domain_iommu *hd = dom_iommu(d);
int rc;
unsigned long pt_mfn[7];
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/7] amd-iommu: re-name u8/16/32/64 to uint8/16/32/64_t
This patch is largely cosmetic. The only non-cosmetic changes are to
re-define the local pde variable as a uint32_t pointer (rather than a
uint64_t pointer) in iommu_merge_pages() and iommu_pde_from_dfn() to allow
the removal of rather excessive amounts of casting.
NOTE: This patch also adds missing emacs boilerplate.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 134 +---
1 file changed, 71 insertions(+), 63 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index 8a10412a07..e4f22c9fc6 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -37,7 +37,7 @@ static unsigned int pfn_to_pde_idx(unsigned long pfn,
unsigned int level)
void clear_iommu_pte_present(unsigned long l1_mfn, unsigned long dfn)
{
-u64 *table, *pte;
+uint64_t *table, *pte;
table = map_domain_page(_mfn(l1_mfn));
pte = table + pfn_to_pde_idx(dfn, IOMMU_PAGING_MODE_LEVEL_1);
@@ -45,15 +45,15 @@ void clear_iommu_pte_present(unsigned long l1_mfn, unsigned
long dfn)
unmap_domain_page(table);
}
-static bool_t set_iommu_pde_present(u32 *pde, unsigned long next_mfn,
+static bool_t set_iommu_pde_present(uint32_t *pde, unsigned long next_mfn,
unsigned int next_level,
bool_t iw, bool_t ir)
{
-u64 addr_lo, addr_hi, maddr_old, maddr_next;
-u32 entry;
+uint64_t addr_lo, addr_hi, maddr_old, maddr_next;
+uint32_t entry;
bool_t need_flush = 0;
-maddr_next = (u64)next_mfn << PAGE_SHIFT;
+maddr_next = (uint64_t)next_mfn << PAGE_SHIFT;
addr_hi = get_field_from_reg_u32(pde[1],
IOMMU_PTE_ADDR_HIGH_MASK,
@@ -71,7 +71,7 @@ static bool_t set_iommu_pde_present(u32 *pde, unsigned long
next_mfn,
addr_hi = maddr_next >> 32;
/* enable read/write permissions,which will be enforced at the PTE */
-set_field_in_reg_u32((u32)addr_hi, 0,
+set_field_in_reg_u32((uint32_t)addr_hi, 0,
IOMMU_PDE_ADDR_HIGH_MASK,
IOMMU_PDE_ADDR_HIGH_SHIFT, );
set_field_in_reg_u32(iw, entry,
@@ -90,7 +90,7 @@ static bool_t set_iommu_pde_present(u32 *pde, unsigned long
next_mfn,
pde[1] = entry;
/* mark next level as 'present' */
-set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
+set_field_in_reg_u32((uint32_t)addr_lo >> PAGE_SHIFT, 0,
IOMMU_PDE_ADDR_LOW_MASK,
IOMMU_PDE_ADDR_LOW_SHIFT, );
set_field_in_reg_u32(next_level, entry,
@@ -108,13 +108,13 @@ static bool_t set_iommu_pte_present(unsigned long pt_mfn,
unsigned long dfn,
unsigned long next_mfn, int pde_level,
bool_t iw, bool_t ir)
{
-u64 *table;
-u32 *pde;
+uint64_t *table;
+uint32_t *pde;
bool_t need_flush = 0;
table = map_domain_page(_mfn(pt_mfn));
-pde = (u32*)(table + pfn_to_pde_idx(dfn, pde_level));
+pde = (uint32_t *)(table + pfn_to_pde_idx(dfn, pde_level));
need_flush = set_iommu_pde_present(pde, next_mfn,
IOMMU_PAGING_MODE_LEVEL_0, iw, ir);
@@ -123,10 +123,10 @@ static bool_t set_iommu_pte_present(unsigned long pt_mfn,
unsigned long dfn,
}
void amd_iommu_set_root_page_table(
-u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid)
+uint32_t *dte, uint64_t root_ptr, uint16_t domain_id, uint8_t paging_mode,
uint8_t valid)
{
-u64 addr_hi, addr_lo;
-u32 entry;
+uint64_t addr_hi, addr_lo;
+uint32_t entry;
set_field_in_reg_u32(domain_id, 0,
IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT, );
@@ -135,7 +135,7 @@ void amd_iommu_set_root_page_table(
addr_lo = root_ptr & DMA_32BIT_MASK;
addr_hi = root_ptr >> 32;
-set_field_in_reg_u32((u32)addr_hi, 0,
+set_field_in_reg_u32((uint32_t)addr_hi, 0,
IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK,
IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT, );
set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
@@ -146,7 +146,7 @@ void amd_iommu_set_root_page_table(
IOMMU_DEV_TABLE_IO_READ_PERMISSION_SHIFT, );
dte[1] = entry;
-set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
+set_field_in_reg_u32((uint32_t)addr_lo >> PAGE_SHIFT, 0,
IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_MASK,
IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT, );
set_field_in_reg_u32(paging_mode, entry,
@@ -162,9 +162,9 @@ void amd_iommu_set_root_page_table(
dte[0] = entry;
}
-void iommu_dte_set_iotlb(u32 *dte, u8 i)
+void iommu_dte_set_iotlb(uint32_t *dte, uint8_t i)
{
-
[Xen-devel] [PATCH 4/7] amd-iommu: reduce code duplication...
...by calling update_paging_mode() inside iommu_pde_from_dfn().
Also have iommu_pde_from_dfn() return -EFAULT if pt_mfn[1] is zero, to avoid
the callers having to explictly test it.
NOTE: The return value of iommu_pde_from_dfn() is ignored by
amd_iommu_map_page(). Instead, to preserve the existing return
semantics, -EFAULT is returned regardless of the actual error.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 276
1 file changed, 138 insertions(+), 138 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index d7df8b9161..a186c8d28b 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -431,6 +431,102 @@ static int iommu_merge_pages(struct domain *d, unsigned
long pt_mfn,
return 0;
}
+static int update_paging_mode(struct domain *d, unsigned long dfn)
+{
+uint16_t bdf;
+void *device_entry;
+unsigned int req_id, level, offset;
+unsigned long flags;
+struct pci_dev *pdev;
+struct amd_iommu *iommu = NULL;
+struct page_info *new_root = NULL;
+struct page_info *old_root = NULL;
+void *new_root_vaddr;
+unsigned long old_root_mfn;
+struct domain_iommu *hd = dom_iommu(d);
+
+ASSERT(dfn != dfn_x(INVALID_DFN));
+ASSERT(!(dfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
+
+level = hd->arch.paging_mode;
+old_root = hd->arch.root_table;
+offset = dfn >> (PTE_PER_TABLE_SHIFT * (level - 1));
+
+ASSERT(spin_is_locked(>arch.mapping_lock) && is_hvm_domain(d));
+
+while ( offset >= PTE_PER_TABLE_SIZE )
+{
+/*
+ * Allocate and install a new root table.
+ * Only upper I/O page table grows, no need to fix next level bits.
+ */
+new_root = alloc_amd_iommu_pgtable();
+if ( !new_root )
+{
+AMD_IOMMU_DEBUG("%s Cannot allocate I/O page table\n",
+__func__);
+return -ENOMEM;
+}
+
+new_root_vaddr = __map_domain_page(new_root);
+old_root_mfn = mfn_x(page_to_mfn(old_root));
+set_iommu_pde_present(new_root_vaddr, old_root_mfn, level,
+ !!IOMMUF_writable, !!IOMMUF_readable);
+
+level++;
+old_root = new_root;
+offset >>= PTE_PER_TABLE_SHIFT;
+unmap_domain_page(new_root_vaddr);
+}
+
+if ( new_root )
+{
+hd->arch.paging_mode = level;
+hd->arch.root_table = new_root;
+
+if ( !pcidevs_locked() )
+AMD_IOMMU_DEBUG("%s Try to access pdev_list "
+"without aquiring pcidevs_lock.\n", __func__);
+
+/*
+ * Update device table entries using new root table and paging
+ * mode.
+ */
+for_each_pdev ( d, pdev )
+{
+bdf = PCI_BDF2(pdev->bus, pdev->devfn);
+iommu = find_iommu_for_device(pdev->seg, bdf);
+if ( !iommu )
+{
+AMD_IOMMU_DEBUG("%s Fail to find iommu.\n", __func__);
+return -ENODEV;
+}
+
+spin_lock_irqsave(>lock, flags);
+do {
+req_id = get_dma_requestor_id(pdev->seg, bdf);
+device_entry = iommu->dev_table.buffer +
+ (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);
+
+/* valid = 0 only works for dom0 passthrough mode */
+amd_iommu_set_root_page_table(
+device_entry, page_to_maddr(hd->arch.root_table),
+d->domain_id, hd->arch.paging_mode, 1);
+
+amd_iommu_flush_device(iommu, req_id);
+bdf += pdev->phantom_stride;
+} while ( PCI_DEVFN2(bdf) != pdev->devfn &&
+ PCI_SLOT(bdf) == PCI_SLOT(pdev->devfn) );
+spin_unlock_irqrestore(>lock, flags);
+}
+
+/* For safety, invalidate all entries */
+amd_iommu_flush_all_pages(d);
+}
+
+return 0;
+}
+
/* Walk io page tables and build level page tables if necessary
* {Re, un}mapping super page frames causes re-allocation of io
* page tables.
@@ -445,23 +541,37 @@ static int iommu_pde_from_dfn(struct domain *d, unsigned
long dfn,
struct page_info *table;
const struct domain_iommu *hd = dom_iommu(d);
+/*
+ * Since HVM domain is initialized with 2 level IO page table,
+ * we might need a deeper page table for wider dfn now.
+ */
+if ( is_hvm_domain(d) )
+{
+int rc = update_paging_mode(d, dfn);
+
+if ( rc )
+{
+AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
+dfn);
+return rc;
+}
+}
+
table = hd->arch.root_table;
level = hd->arch.paging_mode;
-BUG_ON( table == NULL || level <
[Xen-devel] [PATCH 6/7] vtd: change lookup_page failure semantics
Commit 43d1622b "vtd: add lookup_page method to iommu_ops" added a
lookup method in to the VT-d IOMMU implementation. In some cases (such as
when shared EPT is in operation) that function simply passes back an
identity MFN (i.e. an MFN with the same value as the DFN that was passed
in), but this doesn't actually make a lot of sense. If, for instance,
shared EPT is used then really the function should be doing a P2M lookup
since DFN space will be identical to GFN space.
In practice there are no current callers of the lookup_page method and,
when PV-IOMMU support is added, the method will not be called if either
shared EPT is in operation or iommu_passthrough is set, so this patch
simply fails the method with -EOPNOTSUPP in those cases.
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
---
xen/drivers/passthrough/vtd/iommu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 79ecd15e49..1e861b696d 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1853,10 +1853,7 @@ static int intel_iommu_lookup_page(struct domain *d,
dfn_t dfn, mfn_t *mfn,
*/
if ( iommu_use_hap_pt(d) ||
(iommu_hwdom_passthrough && is_hardware_domain(d)) )
-{
-*mfn = _mfn(dfn_x(dfn));
-return 0;
-}
+return -EOPNOTSUPP;
spin_lock(>arch.mapping_lock);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/7] amd-iommu: cleanup and add lookup_page method
The aim of this series is to add a lookup_page method for AMD IOMMU analogous to that recently added for VT-d. That is done by the last patch. The first five patches are cleanup of the AMD IOMMU code, and patch six modifies the VT-d code to remove a semantic problem. Paul Durrant (7): amd-iommu: don't domain_crash() inside map/unmap_page() amd-iommu: re-name u8/16/32/64 to uint8/16/32/64_t amd-iommu: convert all bool_t to bool amd-iommu: reduce code duplication... amd-iommu: introduce new get/set_iommu_pde_info() functions... vtd: change lookup_page failure semantics amd-iommu: add lookup_page method to iommu_ops xen/drivers/passthrough/amd/iommu_map.c | 551 +++--- xen/drivers/passthrough/amd/pci_amd_iommu.c | 1 + xen/drivers/passthrough/vtd/iommu.c | 5 +- xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 + 4 files changed, 317 insertions(+), 242 deletions(-) --- Cc: Andrew Cooper Cc: Brian Woods Cc: Jan Beulich Cc: Kevin Tian Cc: Suravee Suthikulpanit Cc: Wei Liu -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/7] amd-iommu: introduce new get/set_iommu_pde_info() functions...
...and use set_iommu_pde_info() in set_iommu_pde_present().
set_iommu_pde_info() only sets the address and read/write flags in the PDE,
leaving the (PTE-only) FC bit, level value and presence bit to be
subsequently set by set_iommu_pde_present(). A memory barrier is added to
ensure that the presence bit is last to be set.
A subsequent patch will make further use of get_iommu_pde_info().
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 88 +
1 file changed, 56 insertions(+), 32 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index a186c8d28b..fecde9d645 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -45,15 +45,10 @@ void clear_iommu_pte_present(unsigned long l1_mfn, unsigned
long dfn)
unmap_domain_page(table);
}
-static bool set_iommu_pde_present(uint32_t *pde, unsigned long next_mfn,
- unsigned int next_level,
- bool iw, bool ir)
+static void get_iommu_pde_info(uint32_t *pde, uint64_t *maddr, bool *iw,
+ bool *ir)
{
-uint64_t addr_lo, addr_hi, maddr_old, maddr_next;
-uint32_t entry;
-bool need_flush = false;
-
-maddr_next = (uint64_t)next_mfn << PAGE_SHIFT;
+uint64_t addr_lo, addr_hi;
addr_hi = get_field_from_reg_u32(pde[1],
IOMMU_PTE_ADDR_HIGH_MASK,
@@ -61,45 +56,74 @@ static bool set_iommu_pde_present(uint32_t *pde, unsigned
long next_mfn,
addr_lo = get_field_from_reg_u32(pde[0],
IOMMU_PTE_ADDR_LOW_MASK,
IOMMU_PTE_ADDR_LOW_SHIFT);
+*maddr = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
-maddr_old = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
+if ( iw )
+*iw = !!get_field_from_reg_u32(pde[1],
+ IOMMU_PDE_IO_WRITE_PERMISSION_MASK,
+ IOMMU_PDE_IO_WRITE_PERMISSION_SHIFT);
+
+if ( ir )
+*ir = !!get_field_from_reg_u32(pde[1],
+ IOMMU_PDE_IO_READ_PERMISSION_MASK,
+ IOMMU_PDE_IO_READ_PERMISSION_SHIFT);
+}
+
+static bool set_iommu_pde_info(uint32_t *pde, uint64_t maddr, bool iw,
+ bool ir)
+{
+uint64_t addr_lo, addr_hi, maddr_old;
-if ( maddr_old != maddr_next )
-need_flush = 1;
+get_iommu_pde_info(pde, _old, NULL, NULL);
-addr_lo = maddr_next & DMA_32BIT_MASK;
-addr_hi = maddr_next >> 32;
+addr_lo = (maddr & DMA_32BIT_MASK) >> PAGE_SHIFT;
+addr_hi = maddr >> 32;
-/* enable read/write permissions,which will be enforced at the PTE */
set_field_in_reg_u32((uint32_t)addr_hi, 0,
IOMMU_PDE_ADDR_HIGH_MASK,
- IOMMU_PDE_ADDR_HIGH_SHIFT, );
-set_field_in_reg_u32(iw, entry,
+ IOMMU_PDE_ADDR_HIGH_SHIFT, [1]);
+set_field_in_reg_u32(iw, pde[1],
IOMMU_PDE_IO_WRITE_PERMISSION_MASK,
- IOMMU_PDE_IO_WRITE_PERMISSION_SHIFT, );
-set_field_in_reg_u32(ir, entry,
+ IOMMU_PDE_IO_WRITE_PERMISSION_SHIFT, [1]);
+set_field_in_reg_u32(ir, pde[1],
IOMMU_PDE_IO_READ_PERMISSION_MASK,
- IOMMU_PDE_IO_READ_PERMISSION_SHIFT, );
+ IOMMU_PDE_IO_READ_PERMISSION_SHIFT, [1]);
+set_field_in_reg_u32((uint32_t)addr_lo, 0,
+ IOMMU_PDE_ADDR_LOW_MASK,
+ IOMMU_PDE_ADDR_LOW_SHIFT, [0]);
+
+return maddr != maddr_old;
+}
+
+static bool set_iommu_pde_present(uint32_t *pde, unsigned long next_mfn,
+ unsigned int next_level,
+ bool_t iw, bool_t ir)
+{
+bool need_flush = set_iommu_pde_info(pde, next_mfn << PAGE_SHIFT, iw,
+ ir);
-/* FC bit should be enabled in PTE, this helps to solve potential
- * issues with ATS devices
+/*
+ * FC bit should be enabled in PTE, this helps to solve potential
+ * issues with ATS devices.
*/
if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
-set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
- IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, );
-pde[1] = entry;
+set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, pde[1],
+ IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT,
+ [1]);
/* mark next level as 'present' */
-set_field_in_reg_u32((uint32_t)addr_lo >> PAGE_SHIFT, 0,
- IOMMU_PDE_ADDR_LOW_MASK,
- IOMMU_PDE_ADDR_LOW_SHIFT, );
-
[Xen-devel] [PATCH net-next 22/22] net: hsr: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
net/hsr/hsr_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index b8cd43c..a067150 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -233,7 +233,7 @@ static netdev_features_t hsr_fix_features(struct net_device
*dev,
}
-static int hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct hsr_priv *hsr = netdev_priv(dev);
struct hsr_port *master;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 05/22] net: sgi: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/sgi/ioc3-eth.c | 4 ++--
drivers/net/ethernet/sgi/meth.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c
b/drivers/net/ethernet/sgi/ioc3-eth.c
index 18d533f..3140999 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -99,7 +99,7 @@ struct ioc3_private {
static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static void ioc3_set_multicast_list(struct net_device *dev);
-static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ioc3_start_xmit(struct sk_buff *skb, struct net_device
*dev);
static void ioc3_timeout(struct net_device *dev);
static inline unsigned int ioc3_hash(const unsigned char *addr);
static inline void ioc3_stop(struct ioc3_private *ip);
@@ -1390,7 +1390,7 @@ static void ioc3_remove_one(struct pci_dev *pdev)
.remove = ioc3_remove_one,
};
-static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
unsigned long data;
struct ioc3_private *ip = netdev_priv(dev);
diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index ea55abd..703fbbe 100644
--- a/drivers/net/ethernet/sgi/meth.c
+++ b/drivers/net/ethernet/sgi/meth.c
@@ -697,7 +697,7 @@ static void meth_add_to_tx_ring(struct meth_private *priv,
struct sk_buff *skb)
/*
* Transmit a packet (called by the kernel)
*/
-static int meth_tx(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t meth_tx(struct sk_buff *skb, struct net_device *dev)
{
struct meth_private *priv = netdev_priv(dev);
unsigned long flags;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 07/22] net: i825xx: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/i825xx/ether1.c | 5 +++--
drivers/net/ethernet/i825xx/lib82596.c | 4 ++--
drivers/net/ethernet/i825xx/sun3_82586.c | 6 --
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/i825xx/ether1.c
b/drivers/net/ethernet/i825xx/ether1.c
index dc98345..35f6291 100644
--- a/drivers/net/ethernet/i825xx/ether1.c
+++ b/drivers/net/ethernet/i825xx/ether1.c
@@ -64,7 +64,8 @@
#define RX_AREA_END0x0fc00
static int ether1_open(struct net_device *dev);
-static int ether1_sendpacket(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ether1_sendpacket(struct sk_buff *skb,
+struct net_device *dev);
static irqreturn_t ether1_interrupt(int irq, void *dev_id);
static int ether1_close(struct net_device *dev);
static void ether1_setmulticastlist(struct net_device *dev);
@@ -667,7 +668,7 @@
netif_wake_queue(dev);
}
-static int
+static netdev_tx_t
ether1_sendpacket (struct sk_buff *skb, struct net_device *dev)
{
int tmp, tst, nopaddr, txaddr, tbdaddr, dataddr;
diff --git a/drivers/net/ethernet/i825xx/lib82596.c
b/drivers/net/ethernet/i825xx/lib82596.c
index f00a1dc..2f7ae11 100644
--- a/drivers/net/ethernet/i825xx/lib82596.c
+++ b/drivers/net/ethernet/i825xx/lib82596.c
@@ -347,7 +347,7 @@ struct i596_private {
0x7f /* *multi IA */ };
static int i596_open(struct net_device *dev);
-static int i596_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t i596_start_xmit(struct sk_buff *skb, struct net_device
*dev);
static irqreturn_t i596_interrupt(int irq, void *dev_id);
static int i596_close(struct net_device *dev);
static void i596_add_cmd(struct net_device *dev, struct i596_cmd *cmd);
@@ -966,7 +966,7 @@ static void i596_tx_timeout (struct net_device *dev)
}
-static int i596_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t i596_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct i596_private *lp = netdev_priv(dev);
struct tx_cmd *tx_cmd;
diff --git a/drivers/net/ethernet/i825xx/sun3_82586.c
b/drivers/net/ethernet/i825xx/sun3_82586.c
index 8bb15a8..1a86184 100644
--- a/drivers/net/ethernet/i825xx/sun3_82586.c
+++ b/drivers/net/ethernet/i825xx/sun3_82586.c
@@ -121,7 +121,8 @@
static irqreturn_t sun3_82586_interrupt(int irq,void *dev_id);
static int sun3_82586_open(struct net_device *dev);
static int sun3_82586_close(struct net_device *dev);
-static int sun3_82586_send_packet(struct sk_buff *,struct net_device *);
+static netdev_tx_t sun3_82586_send_packet(struct sk_buff *,
+ struct net_device *);
static struct net_device_stats *sun3_82586_get_stats(struct net_device *dev);
static voidset_multicast_list(struct net_device *dev);
static voidsun3_82586_timeout(struct net_device *dev);
@@ -1002,7 +1003,8 @@ static void sun3_82586_timeout(struct net_device *dev)
* send frame
*/
-static int sun3_82586_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+sun3_82586_send_packet(struct sk_buff *skb, struct net_device *dev)
{
int len,i;
#ifndef NO_NOPCOMMANDS
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 06/22] net: wiznet: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/wiznet/w5100.c | 2 +-
drivers/net/ethernet/wiznet/w5300.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/wiznet/w5100.c
b/drivers/net/ethernet/wiznet/w5100.c
index 2bdfb39..d8ba512 100644
--- a/drivers/net/ethernet/wiznet/w5100.c
+++ b/drivers/net/ethernet/wiznet/w5100.c
@@ -835,7 +835,7 @@ static void w5100_tx_work(struct work_struct *work)
w5100_tx_skb(priv->ndev, skb);
}
-static int w5100_start_tx(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t w5100_start_tx(struct sk_buff *skb, struct net_device *ndev)
{
struct w5100_priv *priv = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/wiznet/w5300.c
b/drivers/net/ethernet/wiznet/w5300.c
index 56ae573..80fdbff 100644
--- a/drivers/net/ethernet/wiznet/w5300.c
+++ b/drivers/net/ethernet/wiznet/w5300.c
@@ -365,7 +365,7 @@ static void w5300_tx_timeout(struct net_device *ndev)
netif_wake_queue(ndev);
}
-static int w5300_start_tx(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t w5300_start_tx(struct sk_buff *skb, struct net_device *ndev)
{
struct w5300_priv *priv = netdev_priv(ndev);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 10/22] net: ti: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/ti/cpmac.c| 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
drivers/net/ethernet/ti/netcp_core.c | 8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index 9b8a30b..64c45eb 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -544,7 +544,7 @@ static int cpmac_poll(struct napi_struct *napi, int budget)
}
-static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cpmac_start_xmit(struct sk_buff *skb, struct net_device
*dev)
{
int queue;
unsigned int len;
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index f270bee..b83f32d 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -943,7 +943,7 @@ static void emac_tx_handler(void *token, int len, int
status)
*
* Returns success(NETDEV_TX_OK) or error code (typically out of desc's)
*/
-static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct device *emac_dev = >dev;
int ret_code;
diff --git a/drivers/net/ethernet/ti/netcp_core.c
b/drivers/net/ethernet/ti/netcp_core.c
index 1f61226..2d8cfe8 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1270,7 +1270,8 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
}
/* Submit the packet */
-static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t
+netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct netcp_intf *netcp = netdev_priv(ndev);
struct netcp_stats *tx_stats = >stats;
@@ -1290,7 +1291,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
dev_warn(netcp->ndev_dev, "padding failed (%d), packet
dropped\n",
ret);
tx_stats->tx_dropped++;
- return ret;
+ return NETDEV_TX_BUSY;
}
skb->len = NETCP_MIN_PACKET_SIZE;
}
@@ -1298,7 +1299,6 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
desc = netcp_tx_map_skb(skb, netcp);
if (unlikely(!desc)) {
netif_stop_subqueue(ndev, subqueue);
- ret = -ENOBUFS;
goto drop;
}
@@ -1319,7 +1319,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb,
struct net_device *ndev)
if (desc)
netcp_free_tx_desc_chain(netcp, desc, sizeof(*desc));
dev_kfree_skb(skb);
- return ret;
+ return NETDEV_TX_BUSY;
}
int netcp_txpipe_close(struct netcp_tx_pipe *tx_pipe)
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. YueHaibing (22): net: micrel: fix return type of ndo_start_xmit function net: freescale: fix return type of ndo_start_xmit function net: seeq: fix return type of ndo_start_xmit function net: cirrus: fix return type of ndo_start_xmit function net: sgi: fix return type of ndo_start_xmit function net: wiznet: fix return type of ndo_start_xmit function net: i825xx: fix return type of ndo_start_xmit function net: apple: fix return type of ndo_start_xmit function net: smsc: fix return type of ndo_start_xmit function net: ti: fix return type of ndo_start_xmit function net: faraday: fix return type of ndo_start_xmit function net: ovs: fix return type of ndo_start_xmit function net: xen-netback: fix return type of ndo_start_xmit function net: caif: fix return type of ndo_start_xmit function net: hamradio: fix return type of ndo_start_xmit function usbnet: ipheth: fix return type of ndo_start_xmit function hv_netvsc: fix return type of ndo_start_xmit function can: xilinx: fix return type of ndo_start_xmit function net: plip: fix return type of ndo_start_xmit function rionet: fix return type of ndo_start_xmit function l2tp: fix return type of ndo_start_xmit function net: hsr: fix return type of ndo_start_xmit function drivers/net/caif/caif_hsi.c | 10 +- drivers/net/caif/caif_serial.c| 7 +-- drivers/net/caif/caif_spi.c | 6 +++--- drivers/net/caif/caif_virtio.c| 2 +- drivers/net/can/xilinx_can.c | 2 +- drivers/net/ethernet/apple/bmac.c | 4 ++-- drivers/net/ethernet/apple/mace.c | 4 ++-- drivers/net/ethernet/apple/macmace.c | 4 ++-- drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +- drivers/net/ethernet/cirrus/mac89x0.c | 4 ++-- drivers/net/ethernet/faraday/ftgmac100.c | 4 ++-- drivers/net/ethernet/faraday/ftmac100.c | 7 --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c| 3 ++- drivers/net/ethernet/freescale/fec_mpc52xx.c | 3 ++- drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 3 ++- drivers/net/ethernet/freescale/gianfar.c | 4 ++-- drivers/net/ethernet/freescale/ucc_geth.c | 3 ++- drivers/net/ethernet/i825xx/ether1.c | 5 +++-- drivers/net/ethernet/i825xx/lib82596.c| 4 ++-- drivers/net/ethernet/i825xx/sun3_82586.c | 6 -- drivers/net/ethernet/micrel/ks8695net.c | 2 +- drivers/net/ethernet/micrel/ks8851_mll.c | 4 ++-- drivers/net/ethernet/seeq/ether3.c| 5 +++-- drivers/net/ethernet/seeq/sgiseeq.c | 3 ++- drivers/net/ethernet/sgi/ioc3-eth.c | 4 ++-- drivers/net/ethernet/sgi/meth.c | 2 +- drivers/net/ethernet/smsc/smc911x.c | 3 ++- drivers/net/ethernet/smsc/smc91x.c| 3 ++- drivers/net/ethernet/smsc/smsc911x.c | 3 ++- drivers/net/ethernet/ti/cpmac.c | 2 +- drivers/net/ethernet/ti/davinci_emac.c| 2 +- drivers/net/ethernet/ti/netcp_core.c | 8 drivers/net/ethernet/wiznet/w5100.c | 2 +- drivers/net/ethernet/wiznet/w5300.c | 2 +- drivers/net/hamradio/baycom_epp.c | 3 ++- drivers/net/hamradio/dmascc.c | 4 ++-- drivers/net/hyperv/netvsc_drv.c | 10 +++--- drivers/net/plip/plip.c | 4 ++-- drivers/net/rionet.c | 3 ++- drivers/net/usb/ipheth.c | 2 +- drivers/net/xen-netback/interface.c | 3 ++- net/caif/chnl_net.c | 3 ++- net/hsr/hsr_device.c | 2 +- net/l2tp/l2tp_eth.c | 3 ++- net/openvswitch/vport-internal_dev.c | 5 +++-- 45 files changed, 100 insertions(+), 74 deletions(-) -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 02/22] net: freescale: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c| 3 ++-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 3 ++-
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 3 ++-
drivers/net/ethernet/freescale/gianfar.c | 4 ++--
drivers/net/ethernet/freescale/ucc_geth.c | 3 ++-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index a5131a5..84843de 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2044,7 +2044,8 @@ static inline int dpaa_xmit(struct dpaa_priv *priv,
return 0;
}
-static int dpaa_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
+static netdev_tx_t
+dpaa_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
{
const int queue_mapping = skb_get_queue_mapping(skb);
bool nonlinear = skb_is_nonlinear(skb);
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c
b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 6d7269d..b90bab7 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -305,7 +305,8 @@ static int mpc52xx_fec_close(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct bcom_fec_bd *bd;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 2c2976a..7c548ed 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -481,7 +481,8 @@ static struct sk_buff *tx_skb_align_workaround(struct
net_device *dev,
}
#endif
-static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
cbd_t __iomem *bdp;
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index c488d31..0bd21a4 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -110,7 +110,7 @@
const char gfar_driver_version[] = "2.0";
static int gfar_enet_open(struct net_device *dev);
-static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t gfar_start_xmit(struct sk_buff *skb, struct net_device
*dev);
static void gfar_reset_task(struct work_struct *work);
static void gfar_timeout(struct net_device *dev);
static int gfar_close(struct net_device *dev);
@@ -2332,7 +2332,7 @@ static inline bool gfar_csum_errata_76(struct
gfar_private *priv,
/* This is called by the kernel when a frame is ready for transmission.
* It is pointed to by the dev->hard_start_xmit function pointer
*/
-static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_tx_q *tx_queue = NULL;
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 9600837..32e0270 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3078,7 +3078,8 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
/* This is called by the kernel when a frame is ready for transmission. */
/* It is pointed to by the dev->hard_start_xmit function pointer */
-static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ucc_geth_private *ugeth = netdev_priv(dev);
#ifdef CONFIG_UGETH_TX_ON_DEMAND
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 01/22] net: micrel: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/micrel/ks8695net.c | 2 +-
drivers/net/ethernet/micrel/ks8851_mll.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8695net.c
b/drivers/net/ethernet/micrel/ks8695net.c
index bd51e05..b881f5d 100644
--- a/drivers/net/ethernet/micrel/ks8695net.c
+++ b/drivers/net/ethernet/micrel/ks8695net.c
@@ -1164,7 +1164,7 @@ static int ks8695_poll(struct napi_struct *napi, int
budget)
* sk_buff and adds it to the TX ring. It then kicks the TX DMA
* engine to ensure transmission begins.
*/
-static int
+static netdev_tx_t
ks8695_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct ks8695_priv *ksp = netdev_priv(ndev);
diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c
b/drivers/net/ethernet/micrel/ks8851_mll.c
index 0e9719f..35f8c9e 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -1021,9 +1021,9 @@ static void ks_write_qmu(struct ks_net *ks, u8 *pdata,
u16 len)
* spin_lock_irqsave is required because tx and rx should be mutual exclusive.
* So while tx is in-progress, prevent IRQ interrupt from happenning.
*/
-static int ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t ks_start_xmit(struct sk_buff *skb, struct net_device
*netdev)
{
- int retv = NETDEV_TX_OK;
+ netdev_tx_t retv = NETDEV_TX_OK;
struct ks_net *ks = netdev_priv(netdev);
disable_irq(netdev->irq);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 20/22] rionet: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/rionet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
index e9f101c..de391c7 100644
--- a/drivers/net/rionet.c
+++ b/drivers/net/rionet.c
@@ -170,7 +170,8 @@ static int rionet_queue_tx_msg(struct sk_buff *skb, struct
net_device *ndev,
return 0;
}
-static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t
+rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
int i;
struct rionet_private *rnet = netdev_priv(ndev);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 14/22] net: caif: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/caif/caif_hsi.c| 10 +-
drivers/net/caif/caif_serial.c | 7 +--
drivers/net/caif/caif_spi.c| 6 +++---
drivers/net/caif/caif_virtio.c | 2 +-
net/caif/chnl_net.c| 3 ++-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 433a14b..70c449e 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -1006,7 +1006,7 @@ static void cfhsi_aggregation_tout(struct timer_list *t)
cfhsi_start_tx(cfhsi);
}
-static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfhsi *cfhsi = NULL;
int start_xfer = 0;
@@ -1014,7 +1014,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct
net_device *dev)
int prio;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfhsi = netdev_priv(dev);
@@ -1048,7 +1048,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct
net_device *dev)
if (WARN_ON(test_bit(CFHSI_SHUTDOWN, >bits))) {
spin_unlock_bh(>lock);
cfhsi_abort_tx(cfhsi);
- return -EINVAL;
+ return NETDEV_TX_BUSY;
}
/* Send flow off if number of packets is above high water mark. */
@@ -1072,7 +1072,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct
net_device *dev)
spin_unlock_bh(>lock);
if (aggregate_ready)
cfhsi_start_tx(cfhsi);
- return 0;
+ return NETDEV_TX_OK;
}
/* Delete inactivity timer if started. */
@@ -1102,7 +1102,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct
net_device *dev)
queue_work(cfhsi->wq, >wake_up_work);
}
- return 0;
+ return NETDEV_TX_OK;
}
static const struct net_device_ops cfhsi_netdevops;
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index a0f954f..acb3264 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -275,7 +275,7 @@ static int handle_tx(struct ser_device *ser)
return tty_wr;
}
-static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t caif_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ser_device *ser;
@@ -290,7 +290,10 @@ static int caif_xmit(struct sk_buff *skb, struct
net_device *dev)
ser->common.flowctrl(ser->dev, OFF);
skb_queue_tail(>head, skb);
- return handle_tx(ser);
+ if (handle_tx(ser))
+ return NETDEV_TX_BUSY;
+
+ return NETDEV_TX_OK;
}
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a139..9040658 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -486,12 +486,12 @@ static void cfspi_xfer_done_cb(struct cfspi_ifc *ifc)
complete(>comp);
}
-static int cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfspi *cfspi = NULL;
unsigned long flags;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfspi = netdev_priv(dev);
@@ -512,7 +512,7 @@ static int cfspi_xmit(struct sk_buff *skb, struct
net_device *dev)
cfspi->cfdev.flowctrl(cfspi->ndev, 0);
}
- return 0;
+ return NETDEV_TX_OK;
}
int cfspi_rxfrm(struct cfspi *cfspi, u8 *buf, size_t len)
diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index 2814e0d..f5507db 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -519,7 +519,7 @@ static struct buf_info *cfv_alloc_and_copy_to_shm(struct
cfv_info *cfv,
}
/* Put the CAIF packet on the virtio ring and kick the receiver */
-static int cfv_netdev_tx(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t cfv_netdev_tx(struct sk_buff *skb, struct net_device
*netdev)
{
struct cfv_info *cfv = netdev_priv(netdev);
struct buf_info *buf_info;
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 13e2ae6..30be426 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -211,7 +211,8 @@ static void chnl_flowctrl_cb(struct cflayer *layr, enum
caif_ctrlcmd flow,
}
}
-static int chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct chnl_net *priv;
struct cfpkt *pkt
[Xen-devel] [PATCH net-next 13/22] net: xen-netback: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/xen-netback/interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 92274c2..7e3ea39 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -165,7 +165,8 @@ static u16 xenvif_select_queue(struct net_device *dev,
struct sk_buff *skb,
return vif->hash.mapping[skb_get_hash_raw(skb) % size];
}
-static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 04/22] net: cirrus: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/cirrus/ep93xx_eth.c | 2 +-
drivers/net/ethernet/cirrus/mac89x0.c| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cirrus/ep93xx_eth.c
b/drivers/net/ethernet/cirrus/ep93xx_eth.c
index e2a7029..13dfdfc 100644
--- a/drivers/net/ethernet/cirrus/ep93xx_eth.c
+++ b/drivers/net/ethernet/cirrus/ep93xx_eth.c
@@ -332,7 +332,7 @@ static int ep93xx_poll(struct napi_struct *napi, int budget)
return rx;
}
-static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ep93xx_priv *ep = netdev_priv(dev);
struct ep93xx_tdesc *txd;
diff --git a/drivers/net/ethernet/cirrus/mac89x0.c
b/drivers/net/ethernet/cirrus/mac89x0.c
index 3f8fe8f..6324e80 100644
--- a/drivers/net/ethernet/cirrus/mac89x0.c
+++ b/drivers/net/ethernet/cirrus/mac89x0.c
@@ -113,7 +113,7 @@ struct net_local {
/* Index to functions, as function prototypes. */
static int net_open(struct net_device *dev);
-static int net_send_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t net_send_packet(struct sk_buff *skb, struct net_device
*dev);
static irqreturn_t net_interrupt(int irq, void *dev_id);
static void set_multicast_list(struct net_device *dev);
static void net_rx(struct net_device *dev);
@@ -324,7 +324,7 @@ static int mac89x0_device_probe(struct platform_device
*pdev)
return 0;
}
-static int
+static netdev_tx_t
net_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct net_local *lp = netdev_priv(dev);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 03/22] net: seeq: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/seeq/ether3.c | 5 +++--
drivers/net/ethernet/seeq/sgiseeq.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/seeq/ether3.c
b/drivers/net/ethernet/seeq/ether3.c
index c5bc124..d1bb73b 100644
--- a/drivers/net/ethernet/seeq/ether3.c
+++ b/drivers/net/ethernet/seeq/ether3.c
@@ -77,7 +77,8 @@
static int ether3_rx(struct net_device *dev, unsigned int maxcnt);
static voidether3_tx(struct net_device *dev);
static int ether3_open (struct net_device *dev);
-static int ether3_sendpacket (struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ether3_sendpacket(struct sk_buff *skb,
+ struct net_device *dev);
static irqreturn_t ether3_interrupt (int irq, void *dev_id);
static int ether3_close (struct net_device *dev);
static voidether3_setmulticastlist (struct net_device *dev);
@@ -481,7 +482,7 @@ static void ether3_timeout(struct net_device *dev)
/*
* Transmit a packet
*/
-static int
+static netdev_tx_t
ether3_sendpacket(struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
b/drivers/net/ethernet/seeq/sgiseeq.c
index 573691b..70cce63 100644
--- a/drivers/net/ethernet/seeq/sgiseeq.c
+++ b/drivers/net/ethernet/seeq/sgiseeq.c
@@ -578,7 +578,8 @@ static inline int sgiseeq_reset(struct net_device *dev)
return 0;
}
-static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct sgiseeq_private *sp = netdev_priv(dev);
struct hpc3_ethregs *hregs = sp->hregs;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 21/22] l2tp: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
net/l2tp/l2tp_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 8aadc4f..4173cb1 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -77,7 +77,8 @@ static void l2tp_eth_dev_uninit(struct net_device *dev)
*/
}
-static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct l2tp_eth *priv = netdev_priv(dev);
struct l2tp_session *session = priv->session;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/hyperv/netvsc_drv.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 3af6d8d..056c472 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct
net_device *vf_netdev,
return rc;
}
-static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
+static netdev_tx_t
+netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
{
struct net_device_context *net_device_ctx = netdev_priv(net);
struct hv_netvsc_packet *packet = NULL;
@@ -528,8 +529,11 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
net_device *net)
*/
vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
if (vf_netdev && netif_running(vf_netdev) &&
- !netpoll_tx_running(net))
- return netvsc_vf_xmit(net, vf_netdev, skb);
+ !netpoll_tx_running(net)) {
+ ret = netvsc_vf_xmit(net, vf_netdev, skb);
+ if (ret)
+ return NETDEV_TX_BUSY;
+ }
/* We will atmost need two pages to describe the rndis
* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 18/22] can: xilinx: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/can/xilinx_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 045f084..6de5004 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -612,7 +612,7 @@ static int xcan_start_xmit_mailbox(struct sk_buff *skb,
struct net_device *ndev)
*
* Return: NETDEV_TX_OK on success and NETDEV_TX_BUSY when the tx queue is full
*/
-static int xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
*ndev)
{
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 09/22] net: smsc: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/smsc/smc911x.c | 3 ++-
drivers/net/ethernet/smsc/smc91x.c | 3 ++-
drivers/net/ethernet/smsc/smsc911x.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc911x.c
b/drivers/net/ethernet/smsc/smc911x.c
index b1b53f6..8355dfb 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -513,7 +513,8 @@ static void smc911x_hardware_send_pkt(struct net_device
*dev)
* now, or set the card to generates an interrupt when ready
* for the packet.
*/
-static int smc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+smc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smc911x_local *lp = netdev_priv(dev);
unsigned int free;
diff --git a/drivers/net/ethernet/smsc/smc91x.c
b/drivers/net/ethernet/smsc/smc91x.c
index b944828..8d6cff8 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -638,7 +638,8 @@ static void smc_hardware_send_pkt(unsigned long data)
* now, or set the card to generates an interrupt when ready
* for the packet.
*/
-static int smc_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+smc_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smc_local *lp = netdev_priv(dev);
void __iomem *ioaddr = lp->base;
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index c009407..99a5a8a 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1786,7 +1786,8 @@ static int smsc911x_stop(struct net_device *dev)
}
/* Entry point for transmitting a packet */
-static int smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device
*dev)
+static netdev_tx_t
+smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smsc911x_data *pdata = netdev_priv(dev);
unsigned int freespace;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 15/22] net: hamradio: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/hamradio/baycom_epp.c | 3 ++-
drivers/net/hamradio/dmascc.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 1e62d00..f4ceccf 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -772,7 +772,8 @@ static void epp_bh(struct work_struct *work)
* = network driver interface =
*/
-static int baycom_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+baycom_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct baycom_state *bc = netdev_priv(dev);
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index cde4120..2798870 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -239,7 +239,7 @@ struct scc_info {
static int scc_open(struct net_device *dev);
static int scc_close(struct net_device *dev);
static int scc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
-static int scc_send_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t scc_send_packet(struct sk_buff *skb, struct net_device
*dev);
static int scc_set_mac_address(struct net_device *dev, void *sa);
static inline void tx_on(struct scc_priv *priv);
@@ -921,7 +921,7 @@ static int scc_ioctl(struct net_device *dev, struct ifreq
*ifr, int cmd)
}
-static int scc_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t scc_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct scc_priv *priv = dev->ml_priv;
unsigned long flags;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 19/22] net: plip: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/plip/plip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index feb92ec..0b354e6 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -146,7 +146,7 @@
static void plip_interrupt(void *dev_id);
/* Functions for DEV methods */
-static int plip_tx_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t plip_tx_packet(struct sk_buff *skb, struct net_device *dev);
static int plip_hard_header(struct sk_buff *skb, struct net_device *dev,
unsigned short type, const void *daddr,
const void *saddr, unsigned len);
@@ -962,7 +962,7 @@ static __be16 plip_type_trans(struct sk_buff *skb, struct
net_device *dev)
spin_unlock_irqrestore(>lock, flags);
}
-static int
+static netdev_tx_t
plip_tx_packet(struct sk_buff *skb, struct net_device *dev)
{
struct net_local *nl = netdev_priv(dev);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 11/22] net: faraday: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/faraday/ftgmac100.c | 4 ++--
drivers/net/ethernet/faraday/ftmac100.c | 7 ---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
b/drivers/net/ethernet/faraday/ftgmac100.c
index d8ead7e..4d67322 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -712,8 +712,8 @@ static bool ftgmac100_prep_tx_csum(struct sk_buff *skb, u32
*csum_vlan)
return skb_checksum_help(skb) == 0;
}
-static int ftgmac100_hard_start_xmit(struct sk_buff *skb,
-struct net_device *netdev)
+static netdev_tx_t ftgmac100_hard_start_xmit(struct sk_buff *skb,
+struct net_device *netdev)
{
struct ftgmac100 *priv = netdev_priv(netdev);
struct ftgmac100_txdes *txdes, *first;
diff --git a/drivers/net/ethernet/faraday/ftmac100.c
b/drivers/net/ethernet/faraday/ftmac100.c
index a1197d3..570caeb 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -634,8 +634,8 @@ static void ftmac100_tx_complete(struct ftmac100 *priv)
;
}
-static int ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
-dma_addr_t map)
+static netdev_tx_t ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
+dma_addr_t map)
{
struct net_device *netdev = priv->netdev;
struct ftmac100_txdes *txdes;
@@ -1016,7 +1016,8 @@ static int ftmac100_stop(struct net_device *netdev)
return 0;
}
-static int ftmac100_hard_start_xmit(struct sk_buff *skb, struct net_device
*netdev)
+static netdev_tx_t
+ftmac100_hard_start_xmit(struct sk_buff *skb, struct net_device *netdev)
{
struct ftmac100 *priv = netdev_priv(netdev);
dma_addr_t map;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 12/22] net: ovs: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
net/openvswitch/vport-internal_dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/vport-internal_dev.c
b/net/openvswitch/vport-internal_dev.c
index bb95c43..26f71cb 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -43,7 +43,8 @@ static struct internal_dev *internal_dev_priv(struct
net_device *netdev)
}
/* Called with rcu_read_lock_bh. */
-static int internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t
+internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
{
int len, err;
@@ -62,7 +63,7 @@ static int internal_dev_xmit(struct sk_buff *skb, struct
net_device *netdev)
} else {
netdev->stats.tx_errors++;
}
- return 0;
+ return NETDEV_TX_OK;
}
static int internal_dev_open(struct net_device *netdev)
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 16/22] usbnet: ipheth: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/usb/ipheth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 7275761..53eab6fb 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -413,7 +413,7 @@ static int ipheth_close(struct net_device *net)
return 0;
}
-static int ipheth_tx(struct sk_buff *skb, struct net_device *net)
+static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct net_device *net)
{
struct ipheth_device *dev = netdev_priv(net);
struct usb_device *udev = dev->udev;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next 08/22] net: apple: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/apple/bmac.c| 4 ++--
drivers/net/ethernet/apple/mace.c| 4 ++--
drivers/net/ethernet/apple/macmace.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/apple/bmac.c
b/drivers/net/ethernet/apple/bmac.c
index 024998d..6a8e256 100644
--- a/drivers/net/ethernet/apple/bmac.c
+++ b/drivers/net/ethernet/apple/bmac.c
@@ -154,7 +154,7 @@ struct bmac_data {
static irqreturn_t bmac_rxdma_intr(int irq, void *dev_id);
static void bmac_set_timeout(struct net_device *dev);
static void bmac_tx_timeout(struct timer_list *t);
-static int bmac_output(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t bmac_output(struct sk_buff *skb, struct net_device *dev);
static void bmac_start(struct net_device *dev);
#defineDBDMA_SET(x)( ((x) | (x) << 16) )
@@ -1456,7 +1456,7 @@ static int bmac_close(struct net_device *dev)
spin_unlock_irqrestore(>lock, flags);
}
-static int
+static netdev_tx_t
bmac_output(struct sk_buff *skb, struct net_device *dev)
{
struct bmac_data *bp = netdev_priv(dev);
diff --git a/drivers/net/ethernet/apple/mace.c
b/drivers/net/ethernet/apple/mace.c
index 0b5429d..68b9ee4 100644
--- a/drivers/net/ethernet/apple/mace.c
+++ b/drivers/net/ethernet/apple/mace.c
@@ -78,7 +78,7 @@ struct mace_data {
static int mace_open(struct net_device *dev);
static int mace_close(struct net_device *dev);
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device
*dev);
static void mace_set_multicast(struct net_device *dev);
static void mace_reset(struct net_device *dev);
static int mace_set_address(struct net_device *dev, void *addr);
@@ -525,7 +525,7 @@ static inline void mace_set_timeout(struct net_device *dev)
mp->timeout_active = 1;
}
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
{
struct mace_data *mp = netdev_priv(dev);
volatile struct dbdma_regs __iomem *td = mp->tx_dma;
diff --git a/drivers/net/ethernet/apple/macmace.c
b/drivers/net/ethernet/apple/macmace.c
index 137cbb4..376f2c2 100644
--- a/drivers/net/ethernet/apple/macmace.c
+++ b/drivers/net/ethernet/apple/macmace.c
@@ -89,7 +89,7 @@ struct mace_frame {
static int mace_open(struct net_device *dev);
static int mace_close(struct net_device *dev);
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device
*dev);
static void mace_set_multicast(struct net_device *dev);
static int mace_set_address(struct net_device *dev, void *addr);
static void mace_reset(struct net_device *dev);
@@ -444,7 +444,7 @@ static int mace_close(struct net_device *dev)
* Transmit a frame
*/
-static int mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t mace_xmit_start(struct sk_buff *skb, struct net_device *dev)
{
struct mace_data *mp = netdev_priv(dev);
unsigned long flags;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next 13/22] net: xen-netback: fix return type of ndo_start_xmit function
On Thu, Sep 20, 2018 at 08:32:57PM +0800, YueHaibing wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > > Found by coccinelle. > > Signed-off-by: YueHaibing Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PXE boot with e1000 using OVMF
On Thu, Sep 20, 2018 at 5:34 AM Anthony PERARD wrote: > > On Wed, Sep 19, 2018 at 11:04:22AM -0600, Tamas K Lengyel wrote: > > On Wed, Sep 19, 2018 at 10:36 AM Wei Liu wrote: > > > > > > On Wed, Sep 12, 2018 at 11:54:02AM -0600, Tamas K Lengyel wrote: > > > > HI all, > > > > I'm experimenting with OVMF and I checked to see if OVMF can do PXE > > > > boot out-of-the box with a e1000 emulated network interface and was > > > > surprised to find that it does not. After reading some of the prior > > > > discussions on the topic (https://lists.gt.net/xen/devel/382432 and > > > > https://lists.xenproject.org/archives/html/xen-users/2015-09/msg00059.html) > > > > I was able to get the menu options to show up by copying efi-e1000.rom > > > > that gets installed by Xen's QEMU build into the disk of the VM and > > > > then loading with loadpcirom manually in the EFI shell. From the prior > > > > discussions it sounds to me like this option rom should have been > > > > automatically served by QEMU to OVMF when the VM started as an > > > > OptionROM. So is this a bug or what's missing? > > > > > > Doesn't QEMU load the option ROM automatically when you specify e1000? > > > > > > I _think_ it loads option ROM automatically because I have seen complain > > > that if you configure too many emulated NICs the guest runs out of > > > memory. > > > > I compiled QEMU with DEBUG_PCI enabled in hw/pci/pci.c and then the > > log shows efi-e1000.rom being loaded. However, AFAICT since PCI > > enumeration is disabled in OVMF when running under Xen (I'm not > > exactly sure why) the option rom never gets executed as it only gets > > It's because hvmloader (which is runned before OVMF start) takes care of > enumerating the PCI bus. OVMF only has to read the information: > via OvmfPkg/Library/PciHostBridgeLib/XenSupport.c > > I can try to find out what's needed in order to load an option rom, or > ask on edk2-devel. > That would be much appreciated, please cc me when you do. On KVM option roms just work with OVMF and this is an important feature that's missing when using Xen. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86/hvm: Change return error for offline vcpus
>>> On 20.09.18 at 14:54, wrote: > --- a/xen/arch/x86/hvm/save.c > +++ b/xen/arch/x86/hvm/save.c > @@ -165,7 +165,7 @@ int hvm_save_one(struct domain *d, unsigned int typecode, > unsigned int instance, > if ( (rv = hvm_sr_handlers[typecode].save(v, )) != 0 ) > printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16" > (%d)\n", > d->domain_id, typecode, rv); > -else if ( rv = -ENOENT, ctxt.cur >= sizeof(*desc) ) > +else if ( rv = -ENODATA, ctxt.cur >= sizeof(*desc) ) I think this change of error code should once again only be done for HVMSR_PER_VCPU kind records. For the others no data appearing is _the_ indication of the instance not existing. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case
>>> On 20.09.18 at 14:41, wrote:
> On 13/09/18 11:12, Jan Beulich wrote:
>> The function does two translations in one go for a single guest access.
>> Any failure of the first translation step (guest linear -> guest
>> physical), resulting in #PF, ought to take precedence over any failure
>> of the second step (guest physical -> host physical).
>
> Why? What is the basis of this presumption?
>
> As far as what real hardware does...
>
> This test sets up a ballooned page and a read-only page. I.e. a second
> stage fault on the first part of a misaligned access, and a first stage
> fault on the second part of the access.
>
> (d1) --- Xen Test Framework ---
> (d1) Environment: HVM 64bit (Long mode 4 levels)
> (d1) Test splitfault
> (d1) About to read
> (XEN) *** EPT qual 0181, gpa 0011cffc
> (d1) Reading PTR: got
> (d1) About to write
> (XEN) *** EPT qual 0182, gpa 0011cffc
> (d1) **
> (d1) PANIC: Unhandled exception at 0008:001047e0
> (d1) Vec 14 #PF[-d-sWP] %cr2 0011d000
> (d1) **
>
> The second stage fault is recognised first, which is contrary to your
> presumption, i.e. the code in its current form appears to be correct.
But the guest doesn't know about 2nd stage translation. In the
absence of it, the (1st stage / only) fault ought to occur before
any bus level actions would be taken. Otherwise the code paths
using the mapping function don't match the paths using recently
introduced linear_{read,write}() in this regard.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/AMD: write PAT after ucode update
On 20/09/18 09:40, Jan Beulich wrote: > The increased number of messages (spec_ctrl.c:print_details()) within a > certain time window made me notice some slowness of boot time screen > output. Experimentally I've narrowed the time window to be from > immediately after the early ucode update on the BSP to the PAT write in > cpu_init(). For that reason, as a workaround, write PAT with its > designated value immediately after the ucode load. > > Similar slowness cannot be observed on APs. > > Signed-off-by: Jan Beulich From a straight x86 side of things, Acked-by: Andrew Cooper but I'd still like to get some feedback from AMD. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-indent after "re-arrange get_page_from_le() vs pv_l1tf_check_le()"
On 10/09/18 15:01, Jan Beulich wrote: > That earlier change introduced two "else switch ()" constructs which now > get converted back to "normal" style (indentation). To limit indentation > depth, a conditional gets inverted in ptwr_emulated_update(). > > No functional change intended. > > Requested-by: Andrew Cooper > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] null scheduler bug
I ran some more tests and managed to successfully create and destroy
domU as many times as I want, without any delay between destroy and
create.
I added:
printk("End of a domain_destroy function");
in domain_destroy function and
printk("End of a complete_domain_destroy function"); in
complete_domain_destroy function, at the end of the functions.
Those functions are in domain.c file.
Now, after every xl create it prints:
root@uz3eg-iocc-2018-2:~# xl create bm1.cfg
Parsing config from bm1.cfg
<3>memory_map:add: dom2 gfn=ff0a0 mfn=ff0a0 nr=1
This line never printed before but it doesn't affect anything:
<3>memory_map:add: dom2 gfn=ff0a0 mfn=ff0a0 nr=1
I tried removing printk from functions and I got same problem like before.
Do you guys have any idea what is going on here?
Thanks in advance, best regards!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1] x86/hvm: Change return error for offline vcpus
This patch is needed in order to have a different return error for invalid vcpu
and offline vcpu.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/save.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c
index d520898843..465eb82bc6 100644
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -165,7 +165,7 @@ int hvm_save_one(struct domain *d, unsigned int typecode,
unsigned int instance,
if ( (rv = hvm_sr_handlers[typecode].save(v, )) != 0 )
printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16" (%d)\n",
d->domain_id, typecode, rv);
-else if ( rv = -ENOENT, ctxt.cur >= sizeof(*desc) )
+else if ( rv = -ENODATA, ctxt.cur >= sizeof(*desc) )
{
uint32_t off;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/3] x86/altp2m: Add a hvmop for querying the suppress #VE bit
On 09/03/2018 04:48 PM, Adrian Pop wrote:
> Signed-off-by: Adrian Pop
> ---
> tools/libxc/include/xenctrl.h | 2 ++
> tools/libxc/xc_altp2m.c | 26 +++
> xen/arch/x86/hvm/hvm.c | 19 ++
> xen/arch/x86/mm/mem_access.c| 45 +
> xen/include/public/hvm/hvm_op.h | 2 ++
> xen/include/xen/mem_access.h| 3 +++
> 6 files changed, 97 insertions(+)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index cc8b3e7dce..59955f0357 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1954,6 +1954,8 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
> uint32_t domid,
> uint16_t view_id);
> int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool sve);
> +int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t gfn, bool *sve);
> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
> uint16_t view_id, xen_pfn_t gfn,
> xenmem_access_t access);
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index f883d0b392..1c9b572e2b 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -163,6 +163,32 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
> uint32_t domid,
> return rc;
> }
>
> +int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t gfn, bool *sve)
> +{
> +int rc;
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_get_suppress_ve;
> +arg->domain = domid;
> +arg->u.suppress_ve.view = view_id;
> +arg->u.suppress_ve.gfn = gfn;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +if ( !rc )
> +*sve = arg->u.suppress_ve.suppress_ve;
> +
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> +
> int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool sve)
> {
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 64ab36ff53..6f6efb0d8a 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4525,6 +4525,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_destroy_p2m:
> case HVMOP_altp2m_switch_p2m:
> case HVMOP_altp2m_set_suppress_ve:
> +case HVMOP_altp2m_get_suppress_ve:
> case HVMOP_altp2m_set_mem_access:
> case HVMOP_altp2m_set_mem_access_multi:
> case HVMOP_altp2m_change_gfn:
> @@ -4655,6 +4656,24 @@ static int do_altp2m_op(
> }
> break;
>
> +case HVMOP_altp2m_get_suppress_ve:
> +if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
> +rc = -EINVAL;
> +else
> +{
> +gfn_t gfn = _gfn(a.u.suppress_ve.gfn);
> +unsigned int altp2m_idx = a.u.suppress_ve.view;
> +bool suppress_ve;
> +
> +rc = p2m_get_suppress_ve(d, gfn, _ve, altp2m_idx);
> +if ( !rc )
> +{
> +a.u.suppress_ve.suppress_ve = suppress_ve;
> +rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
> +}
> +}
> +break;
> +
> case HVMOP_altp2m_set_mem_access:
> if ( a.u.set_mem_access.pad )
> rc = -EINVAL;
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 4d49025cbe..df78c93cfd 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -550,6 +550,51 @@ out:
> return rc;
> }
>
> +int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
> +unsigned int altp2m_idx)
> +{
> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
> +struct p2m_domain *ap2m = NULL;
> +struct p2m_domain *p2m;
> +mfn_t mfn;
> +p2m_access_t a;
> +p2m_type_t t;
> +
> +if ( !cpu_has_vmx_virt_exceptions )
> +return -EOPNOTSUPP;
> +
> +/* #VE should be enabled for this vcpu. */
> +if ( gfn_eq(vcpu_altp2m(current).veinfo_gfn, INVALID_GFN) )
> +return -ENXIO;
Basically the same comments as for 2/3: Move to p2m.c, and get rid of
the vmx-ism.
Anothre idea is to get rid of these checks altogether -- returning
'false' when the feature isn't supported or enabled shouldn't be a big
deal. But I don't feel strongly enough about it to argue either way.
-George
___
Xen-devel mailing list
Re: [Xen-devel] x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Minutes
Hi all: I just noticed that the Minutes link at https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit?usp=sharing did not allow people to edit the page. Apologies. This is fixed now. Feel free to make corrections. I will wait for a couple of days before sending out the official meeting minutes. Lars From: Lars Kurth Date: Thursday, 13 September 2018 at 13:05 To: xen-devel Subject: Re: x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Agenda This email seems to not have gone through to xen-devel@ … resending and removing the CC list such that I can link to the slides From: Daniel Smith Date: Wednesday, 12 September 2018 at 13:30 To: Lars Kurth Cc: xen-devel , "committ...@xenproject.org" , Tamas K Lengyel , "intel-...@intel.com" , "daniel.ki...@oracle.com" , Roger Monne , Christopher Clark , Rich Persaud , Brian Woods , Stefano Stabellini , Julien Grall , Juergen Gross , Paul Durrant , "Ji, John" , "Natarajan, Janakarajan" , "edgar.igles...@xilinx.com" , "davorin.mi...@aggios.com" , "robin.randh...@arm.com" , Artem Mygaiev , Matt Spencer , "anastassios.na...@onapp.com" , Stewart Hildebrand , "vfac...@de.adit-jv.com" , Volodymyr Babchuk , "mirela.simono...@aggios.com" , Jarvis Roach Subject: Re: x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Agenda All, I have attached slides for today's talk (Xen measured boot.pdf) as well as the slides from my Platform Security Summit talk (PSEC slides.pdf). V/r, Daniel P. Smith Apertus Solutions, LLC ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case
On 13/09/18 11:12, Jan Beulich wrote: > The function does two translations in one go for a single guest access. > Any failure of the first translation step (guest linear -> guest > physical), resulting in #PF, ought to take precedence over any failure > of the second step (guest physical -> host physical). Why? What is the basis of this presumption? As far as what real hardware does... This test sets up a ballooned page and a read-only page. I.e. a second stage fault on the first part of a misaligned access, and a first stage fault on the second part of the access. (d1) --- Xen Test Framework --- (d1) Environment: HVM 64bit (Long mode 4 levels) (d1) Test splitfault (d1) About to read (XEN) *** EPT qual 0181, gpa 0011cffc (d1) Reading PTR: got (d1) About to write (XEN) *** EPT qual 0182, gpa 0011cffc (d1) ** (d1) PANIC: Unhandled exception at 0008:001047e0 (d1) Vec 14 #PF[-d-sWP] %cr2 0011d000 (d1) ** The second stage fault is recognised first, which is contrary to your presumption, i.e. the code in its current form appears to be correct. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios baseline-only test] 75254: trouble: blocked/broken
This run is configured for baseline tests only. flight 75254 seabios real [real] http://osstest.xensource.com/osstest/logs/75254/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-amd64-pvopsbroken build-amd64 broken build-i386-pvops broken build-i386 broken build-i386-xsm broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-i3864 host-install(4) broken baseline untested build-amd64 4 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested version targeted for testing: seabios bf8e4f902c3608f9e76bba3710812e51560a2ccc baseline version: seabios bcd82420a32d1fe597a88e601959e9d5fe4c70df Last test of basis75214 2018-09-13 12:49:43 Z6 days Testing same since75254 2018-09-20 03:49:48 Z0 days1 attempts People who touched revisions under test: Matt DeVillier jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked
Re: [Xen-devel] [PATCH v5 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit
On 9/20/18 2:34 PM, George Dunlap wrote:
> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
>> domain to change the value of the #VE suppress bit for a page.
>>
>> Add a libxc wrapper for invoking this hvmop.
>>
>> Signed-off-by: Adrian Pop
>> Acked-by: Wei Liu
>> Acked-by: Tamas K Lengyel
>
> Sorry I haven't had a chance to weigh in on this one yet. A couple fo
> comments...
>
>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index e1522a0b75..4d49025cbe 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -495,6 +495,61 @@ void arch_p2m_set_access_required(struct domain *d,
>> bool access_required)
>> }
>> }
>>
>> +/*
>> + * Set/clear the #VE suppress bit for a page. Only available on VMX.
>> + */
>> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
>> +unsigned int altp2m_idx)
>
> This should clearly be in p2m.c, and...
>
>> +{
>> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>> +struct p2m_domain *ap2m = NULL;
>> +struct p2m_domain *p2m;
>> +mfn_t mfn;
>> +p2m_access_t a;
>> +p2m_type_t t;
>> +int rc;
>> +
>> +if ( !cpu_has_vmx_virt_exceptions )
>> +return -EOPNOTSUPP;
>
> We should avoid Intel-specific checks in common code.
>
> In fact, this is wrong, because you can choose to run a guest in shadow
> mode even on a system with virt exceptions -- in which case you'd
> trigger the ASSERT() in p2m-pt.c:p2m_pt_set_entry().
>
> Probably what should happen is that we should move the vmx check into
> p2m-ept.c:p2m_ept_set_entry(), and replace the ASSERT(sve = 0) in
> p2m-pt.c:p2m_pt_set_entry() with "if ( sve != 0 ) return -ENOTSUPP;".
>
> Although what should probably *really* happen is that
> `HVMOP_altp2m_vcpu_enable_notify` should fail with -EOPNOTSUPP instead
> of silently succeeding.
>
> Everything else looks good.
>
> I realize this has been checked in already; no need to revert if you can
> send a follow-up patch in the next couple of (business) days.
Thanks for the review! I'll submit a follow up patch as soon as possible.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit
On 09/03/2018 04:48 PM, Adrian Pop wrote:
> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> domain to change the value of the #VE suppress bit for a page.
>
> Add a libxc wrapper for invoking this hvmop.
>
> Signed-off-by: Adrian Pop
> Acked-by: Wei Liu
> Acked-by: Tamas K Lengyel
Sorry I haven't had a chance to weigh in on this one yet. A couple fo
comments...
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index e1522a0b75..4d49025cbe 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -495,6 +495,61 @@ void arch_p2m_set_access_required(struct domain *d, bool
> access_required)
> }
> }
>
> +/*
> + * Set/clear the #VE suppress bit for a page. Only available on VMX.
> + */
> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
> +unsigned int altp2m_idx)
This should clearly be in p2m.c, and...
> +{
> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
> +struct p2m_domain *ap2m = NULL;
> +struct p2m_domain *p2m;
> +mfn_t mfn;
> +p2m_access_t a;
> +p2m_type_t t;
> +int rc;
> +
> +if ( !cpu_has_vmx_virt_exceptions )
> +return -EOPNOTSUPP;
We should avoid Intel-specific checks in common code.
In fact, this is wrong, because you can choose to run a guest in shadow
mode even on a system with virt exceptions -- in which case you'd
trigger the ASSERT() in p2m-pt.c:p2m_pt_set_entry().
Probably what should happen is that we should move the vmx check into
p2m-ept.c:p2m_ept_set_entry(), and replace the ASSERT(sve = 0) in
p2m-pt.c:p2m_pt_set_entry() with "if ( sve != 0 ) return -ENOTSUPP;".
Although what should probably *really* happen is that
`HVMOP_altp2m_vcpu_enable_notify` should fail with -EOPNOTSUPP instead
of silently succeeding.
Everything else looks good.
I realize this has been checked in already; no need to revert if you can
send a follow-up patch in the next couple of (business) days.
Thanks,
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] PXE boot with e1000 using OVMF
On Wed, Sep 19, 2018 at 11:04:22AM -0600, Tamas K Lengyel wrote: > On Wed, Sep 19, 2018 at 10:36 AM Wei Liu wrote: > > > > On Wed, Sep 12, 2018 at 11:54:02AM -0600, Tamas K Lengyel wrote: > > > HI all, > > > I'm experimenting with OVMF and I checked to see if OVMF can do PXE > > > boot out-of-the box with a e1000 emulated network interface and was > > > surprised to find that it does not. After reading some of the prior > > > discussions on the topic (https://lists.gt.net/xen/devel/382432 and > > > https://lists.xenproject.org/archives/html/xen-users/2015-09/msg00059.html) > > > I was able to get the menu options to show up by copying efi-e1000.rom > > > that gets installed by Xen's QEMU build into the disk of the VM and > > > then loading with loadpcirom manually in the EFI shell. From the prior > > > discussions it sounds to me like this option rom should have been > > > automatically served by QEMU to OVMF when the VM started as an > > > OptionROM. So is this a bug or what's missing? > > > > Doesn't QEMU load the option ROM automatically when you specify e1000? > > > > I _think_ it loads option ROM automatically because I have seen complain > > that if you configure too many emulated NICs the guest runs out of > > memory. > > I compiled QEMU with DEBUG_PCI enabled in hw/pci/pci.c and then the > log shows efi-e1000.rom being loaded. However, AFAICT since PCI > enumeration is disabled in OVMF when running under Xen (I'm not > exactly sure why) the option rom never gets executed as it only gets It's because hvmloader (which is runned before OVMF start) takes care of enumerating the PCI bus. OVMF only has to read the information: via OvmfPkg/Library/PciHostBridgeLib/XenSupport.c I can try to find out what's needed in order to load an option rom, or ask on edk2-devel. > called from the enumeration route > (https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h#L63). > At least that's my current understanding of how option roms work under > OVMF. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 127835: tolerable all pass - PUSHED
flight 127835 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/127835/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 3e828f882a6b54d65f062c1e4c7895f3747bc790 baseline version: xen 889b200cb521aaf8d175a872c856e8e570c1c044 Last test of basis 127819 2018-09-19 18:00:30 Z0 days Testing same since 127835 2018-09-20 09:00:39 Z0 days1 attempts People who touched revisions under test: Adrian Pop Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 889b200cb5..3e828f882a 3e828f882a6b54d65f062c1e4c7895f3747bc790 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxl: keep assigned pci devices across domain reboots
Fill the from_xenstore libxl_device_type hook for PCI devices so that
libxl_retrieve_domain_configuration can properly retrieve PCI devices
from xenstore.
This fixes disappearing pci devices across domain reboots.
Reported-by: Andreas Kinzler
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andreas Kinzler
---
tools/libxl/libxl_pci.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4755a0c93c..87afa03d9e 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1549,8 +1549,7 @@ int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t
domid,
static void libxl__device_pci_from_xs_be(libxl__gc *gc,
const char *be_path,
- libxl_device_pci *pci,
- int nr)
+ int nr, libxl_device_pci *pci)
{
char *s;
unsigned int domain = 0, bus = 0, dev = 0, func = 0, vdevfn = 0;
@@ -1604,7 +1603,7 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx,
uint32_t domid, int *num
pcidevs = calloc(n, sizeof(libxl_device_pci));
for (i = 0; i < n; i++)
-libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
+libxl__device_pci_from_xs_be(gc, be_path, i, pcidevs + i);
*num = n;
out:
@@ -1688,7 +1687,9 @@ static int libxl_device_pci_compare(libxl_device_pci *d1,
#define libxl__device_pci_update_devid NULL
-DEFINE_DEVICE_TYPE_STRUCT_X(pcidev, pci, PCI);
+DEFINE_DEVICE_TYPE_STRUCT_X(pcidev, pci, PCI,
+.from_xenstore = (device_from_xenstore_fn_t)libxl__device_pci_from_xs_be,
+);
/*
* Local variables:
--
2.19.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing baseline-only test] 75251: trouble: blocked/broken
This run is configured for baseline tests only. flight 75251 xen-4.10-testing real [real] http://osstest.xensource.com/osstest/logs/75251/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken build-i386-prev broken build-armhf 4 host-install(4) broken REGR. vs. 75124 build-armhf-pvops 4 host-install(4) broken REGR. vs. 75124 build-i386-pvops 4 host-install(4) broken REGR. vs. 75124 build-i386-xsm4 host-install(4) broken REGR. vs. 75124 build-i386-prev 4 host-install(4) broken REGR. vs. 75124 build-i3864 host-install(4) broken REGR. vs. 75124 build-amd64-prev 4 host-install(4) broken REGR. vs. 75124 build-amd64-xsm 4 host-install(4) broken REGR. vs. 75124 build-amd64 4 host-install(4) broken REGR. vs. 75124 build-amd64-xtf 4 host-install(4) broken REGR. vs. 75124 build-amd64-pvops 4 host-install(4) broken REGR. vs. 75124 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1)
[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 66a9274cc3435117783cd3f07b238309d7f9c6de Bug not present: 391266f0120c92ce8eb5bdb4a41bd314daaf6070 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/127832/ commit 66a9274cc3435117783cd3f07b238309d7f9c6de Author: Roger Pau Monné Date: Fri Sep 7 11:08:00 2018 +0200 iommu: make iommu_inclusive_mapping a suboption of dom0-iommu Introduce a new dom0-iommu=map-inclusive generic option that supersedes iommu_inclusive_mapping. The previous behavior is preserved and the option should only be enabled by default on Intel hardware. Signed-off-by: Roger Pau Monné Reviewed-by: Paul Durrant Reviewed-by: Jan Beulich Reviewed-by: Kevin Tian Acked-by: Julien Grall Acked-by: Suravee Suthikulpanit For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm.xen-boot --summary-out=tmp/127832.bisection-summary --basis-template=127541 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm xen-boot Searching for failure / basis pass: 127595 fail [host=elbling0] / 127541 [host=pinot1] 127520 [host=chardonnay1] 127504 [host=baroque0] 127489 [host=albana1] 127429 [host=baroque1] 127407 [host=albana0] 127369 [host=rimava1] 127350 [host=joubertin0] 127301 [host=italia0] 127280 [host=fiano0] 127266 [host=pinot0] 127232 [host=huxelrebe1] 127123 ok. Failure / basis pass flights: 127595 / 127123 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 d7c60727a3f26b7fda49c8de188dd1cec021d23a Basis pass f4c88459f7c9320f587b839c3d24a2a9dc18a8a0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 f04955e18502035121776f6e09d83ae5a36c773c Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#f4c88459f7c9320f587b839c3d24a2a9dc18a8a0-7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f04955e18502035121776f6e09d83ae5a36c773c-d7c60727a3f26b7fda49c8de188dd1cec021d23a Loaded 2001 nodes in revision graph Searching for test results: 127070 [host=elbling1] 127012 [host=chardonnay1] 127123 pass f4c88459f7c9320f587b839c3d24a2a9dc18a8a0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 f04955e18502035121776f6e09d83ae5a36c773c 127232 [host=huxelrebe1] 127266 [host=pinot0] 127280 [host=fiano0] 127301 [host=italia0] 127350 [host=joubertin0] 127369 [host=rimava1] 127407 [host=albana0] 127429 [host=baroque1] 127489 [host=albana1] 127541 [host=pinot1] 127504 [host=baroque0] 127520 [host=chardonnay1] 127595 fail 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 d7c60727a3f26b7fda49c8de188dd1cec021d23a 127814 fail 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 eea4ec2b66dad87ec745778ab9f00e12ef0f2760 127810 pass 7fe7a0f4c5cf9e7f5b7cb67c1341cdbf62ed4c30 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986
Re: [Xen-devel] [PATCH] x86/mm: re-indent after "re-arrange get_page_from_le() vs pv_l1tf_check_le()"
On Mon, Sep 10, 2018 at 08:01:39AM -0600, Jan Beulich wrote: > That earlier change introduced two "else switch ()" constructs which now > get converted back to "normal" style (indentation). To limit indentation > depth, a conditional gets inverted in ptwr_emulated_update(). > > No functional change intended. > > Requested-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing baseline-only test] 75252: trouble: blocked/broken
This run is configured for baseline tests only. flight 75252 xen-4.11-testing real [real] http://osstest.xensource.com/osstest/logs/75252/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken build-i386-prev broken build-armhf-pvops 4 host-install(4) broken REGR. vs. 75118 build-armhf 4 host-install(4) broken REGR. vs. 75118 build-i386-xsm4 host-install(4) broken REGR. vs. 75118 build-i3864 host-install(4) broken REGR. vs. 75118 build-i386-pvops 4 host-install(4) broken REGR. vs. 75118 build-amd64-pvops 4 host-install(4) broken REGR. vs. 75118 build-i386-prev 4 host-install(4) broken REGR. vs. 75118 build-amd64-xtf 4 host-install(4) broken REGR. vs. 75118 build-amd64 4 host-install(4) broken REGR. vs. 75118 build-amd64-prev 4 host-install(4) broken REGR. vs. 75118 build-amd64-xsm 4 host-install(4) broken REGR. vs. 75118 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1)
[Xen-devel] [PATCH v2] x86/AMD: write PAT after ucode update
The increased number of messages (spec_ctrl.c:print_details()) within a certain time window made me notice some slowness of boot time screen output. Experimentally I've narrowed the time window to be from immediately after the early ucode update on the BSP to the PAT write in cpu_init(). For that reason, as a workaround, write PAT with its designated value immediately after the ucode load. Similar slowness cannot be observed on APs. Signed-off-by: Jan Beulich --- RFC dropped, but still: Preferably to be confirmed by AMD. --- v2: Re-base. --- a/xen/arch/x86/microcode_amd.c +++ b/xen/arch/x86/microcode_amd.c @@ -226,6 +226,13 @@ static int apply_microcode(unsigned int return -EIO; } +/* + * Experimentally this helps with performance issues on at least certain + * Fam15 models. Oddly enough only the BSP is affected, but to be on the + * safe side, do the write uniformly. + */ +wrmsrl(MSR_IA32_CR_PAT, XEN_MSR_PAT); + printk(KERN_WARNING "microcode: CPU%d updated from revision %#x to %#x\n", cpu, uci->cpu_sig.rev, hdr->patch_id); ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/3] x86/altp2m: Add a hvmop for querying the suppress #VE bit
On Thu, Sep 20, 2018 at 08:53:26AM +0100, Wei Liu wrote: > On Thu, Sep 20, 2018 at 10:46:01AM +0300, Razvan Cojocaru wrote: > > On 9/19/18 5:48 PM, Wei Liu wrote: > > > On Mon, Sep 03, 2018 at 06:48:36PM +0300, Adrian Pop wrote: > > >> Signed-off-by: Adrian Pop > > > > > > Acked-by: Wei Liu > > > > > > FAOD I'm expecting you to address Tamas' comment in patch 1 and resend. > > > > Hello Wei, > > > > That has already been addressed in V6, and the patch is already in: > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=eea4ec2b66dad87ec745778ab9f00e12ef0f2760 > > Yep. Saw that yesterday and I committed the last two patches of v6. Actually those patches will need acks from George, too. I will wait until EOD to revert them. Sorry, my memory is completely wrong regarding the maintainership of altp2m code. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On 9/20/18 11:31 AM, Wei Liu wrote: Reviewed-by: Tamas K Lengyel >>> Are there any issues preventing this patch to go in? Possibly missing acks? >> Well, afaics the patch has no x86 maintainer ack, nor - considering it's >> an mm function sitting in the "wrong" file, at least one from the mm >> maintainer. As mentioned a number of times before, it is the submitter's >> responsibility to chase acks, not the committers' or maintainers'. > > Oh, sorry. I have missed that this at least needs an ack from George. > I will wait until EOD for George to give an ack. If there isn't one by > then I will revert the patch in staging. Added George to the email recipients. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
>>> On 20.09.18 at 10:11, wrote: > Are there any issues preventing this patch to go in? Possibly missing acks? Oh, and btw - irrespective what MAINTAINERS says - patches to this function would better also be Cc-ed to George as the mm maintainer. Even more so that I think it has become clear from past discussions that I'm not going to ack any patches to this function, the existence / placement of which I question in the first place. It's just that, with recent clarifications, I won't object to any such additions anymore. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On Thu, Sep 20, 2018 at 02:22:29AM -0600, Jan Beulich wrote:
> >>> On 20.09.18 at 10:11, wrote:
> > On 9/6/18 1:27 AM, Tamas K Lengyel wrote:
> >> On Wed, Sep 5, 2018 at 12:45 PM Andrew Cooper
> > wrote:
> >>>
> >>> On 05/09/18 19:40, Tamas K Lengyel wrote:
> On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
> wrote:
> > On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
> >> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
> >> wrote:
> >>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop
> wrote:
> > In a classic HVI + Xen setup, the introspection engine would monitor
> > legacy guest page-tables by marking them read-only inside the EPT;
> > this
> > way any modification explicitly made by the guest or implicitly
> > made by
> > the CPU page walker would trigger an EPT violation, which would be
> > forwarded by Xen to the SVA and thus the HVI agent. The HVI agent
> > would
> > analyse the modification, and act upon it - for example, a virtual
> > page
> > may be remapped (its guest physical address changed inside the
> > page-table), in which case the introspection logic would update the
> > protection accordingly (remove EPT hook on the old gpa, and place a
> > new
> > EPT hook on the new gpa). In other cases, the modification may be
> > of no
> > interest to the introspection engine - for example, the
> > accessed/dirty
> > bits may be cleared by the operating system or the accessed/dirty
> > bits
> > may be set by the CPU page walker.
> >
> > In our tests we discovered that the vast majority of guest
> > page-table
> > modifications fall in the second category (especially on Windows 10
> > RS4
> > x64 - more than 95% of ALL the page-table modifications are
> > irrelevant to
> > us) - they are of no interest to the introspection logic, but they
> > trigger a very costly EPT violation nonetheless. Therefore, we
> > decided
> > to make use of the new #VE & VMFUNC features in recent Intel CPUs to
> > accelerate the guest page-tables monitoring in the following way:
> >
> > 1. Each monitored page-table would be flagged as being convertible
> >inside the EPT, thus enabling the CPU to deliver a virtualization
> >exception to he guest instead of generating a traditional EPT
> >violation.
> > 2. We inject a small filtering driver inside the protected guest VM,
> >which would intercept the virtualization exception in order to
> > handle
> >guest page-table modifications.
> > 3. We create a dedicated EPT view (altp2m) for the in-guest agent,
> > which
> >would isolate the agent from the rest of the operating system;
> > the
> >agent will switch in and out of the protected EPT view via the
> > VMFUNC
> >instruction placed inside a trampoline page, thus making the
> > agent
> >immune to malicious code inside the guest.
> >
> > This way, all the page-table accesses would generate a
> > virtualization-exception inside the guest instead of a costly EPT
> > violation; the #VE agent would emulate and analyse the
> > modification, and
> > decide whether it is relevant for the main introspection logic; if
> > it is
> > relevant, it would do a VMCALL and notify the introspection engine
> > about the modification; otherwise, it would resume normal
> > instruction
> > execution, thus avoiding a very costly VM exit.
> >
> > Signed-off-by: Adrian Pop
> > ---
> > Changes in v2:
> > - remove the "__get_vcpu()" helper
> > ---
> > tools/libxc/xc_altp2m.c | 1 -
> > xen/arch/x86/hvm/hvm.c | 19 ++-
> > 2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> > index ce4a1e4d60..528e929d7a 100644
> > --- a/tools/libxc/xc_altp2m.c
> > +++ b/tools/libxc/xc_altp2m.c
> > @@ -68,7 +68,6 @@ int xc_altp2m_set_domain_state(xc_interface
> > *handle,
> > uint32_t dom, bool state)
> > return rc;
> > }
> >
> > -/* This is a bit odd to me that it acts on current.. */
> > int xc_altp2m_set_vcpu_enable_notify(xc_interface *handle,
> > uint32_t domid,
> > uint32_t vcpuid, xen_pfn_t
> > gfn)
> > {
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index
Re: [Xen-devel] [PATCH v3] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
>>> On 19.09.18 at 11:13, wrote: > Identity mapping RAM regions on the low 1MB for Dom0 is not ideal, > since there's data there that could be used by Xen during runtime > (like the AP trampoline), so instead of identity mapping the low 1MB > into the Dom0 physmap populate those RAM regions and copy the data. > > Note that this allows to remove unshare_xen_page_with_guest since the > only caller was the PVH Dom0 builder. > > Signed-off-by: Roger Pau Monné > Acked-by: George Dunlap > Reviewed-by: Wei Liu Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
>>> On 20.09.18 at 10:11, wrote:
> On 9/6/18 1:27 AM, Tamas K Lengyel wrote:
>> On Wed, Sep 5, 2018 at 12:45 PM Andrew Cooper
> wrote:
>>>
>>> On 05/09/18 19:40, Tamas K Lengyel wrote:
On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
wrote:
> On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
>> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
>> wrote:
>>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop
wrote:
> In a classic HVI + Xen setup, the introspection engine would monitor
> legacy guest page-tables by marking them read-only inside the EPT;
> this
> way any modification explicitly made by the guest or implicitly made
> by
> the CPU page walker would trigger an EPT violation, which would be
> forwarded by Xen to the SVA and thus the HVI agent. The HVI agent
> would
> analyse the modification, and act upon it - for example, a virtual
> page
> may be remapped (its guest physical address changed inside the
> page-table), in which case the introspection logic would update the
> protection accordingly (remove EPT hook on the old gpa, and place a
> new
> EPT hook on the new gpa). In other cases, the modification may be of
> no
> interest to the introspection engine - for example, the accessed/dirty
> bits may be cleared by the operating system or the accessed/dirty bits
> may be set by the CPU page walker.
>
> In our tests we discovered that the vast majority of guest page-table
> modifications fall in the second category (especially on Windows 10
> RS4
> x64 - more than 95% of ALL the page-table modifications are
> irrelevant to
> us) - they are of no interest to the introspection logic, but they
> trigger a very costly EPT violation nonetheless. Therefore, we
> decided
> to make use of the new #VE & VMFUNC features in recent Intel CPUs to
> accelerate the guest page-tables monitoring in the following way:
>
> 1. Each monitored page-table would be flagged as being convertible
>inside the EPT, thus enabling the CPU to deliver a virtualization
>exception to he guest instead of generating a traditional EPT
>violation.
> 2. We inject a small filtering driver inside the protected guest VM,
>which would intercept the virtualization exception in order to
> handle
>guest page-table modifications.
> 3. We create a dedicated EPT view (altp2m) for the in-guest agent,
> which
>would isolate the agent from the rest of the operating system; the
>agent will switch in and out of the protected EPT view via the
> VMFUNC
>instruction placed inside a trampoline page, thus making the agent
>immune to malicious code inside the guest.
>
> This way, all the page-table accesses would generate a
> virtualization-exception inside the guest instead of a costly EPT
> violation; the #VE agent would emulate and analyse the modification,
> and
> decide whether it is relevant for the main introspection logic; if it
> is
> relevant, it would do a VMCALL and notify the introspection engine
> about the modification; otherwise, it would resume normal instruction
> execution, thus avoiding a very costly VM exit.
>
> Signed-off-by: Adrian Pop
> ---
> Changes in v2:
> - remove the "__get_vcpu()" helper
> ---
> tools/libxc/xc_altp2m.c | 1 -
> xen/arch/x86/hvm/hvm.c | 19 ++-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index ce4a1e4d60..528e929d7a 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -68,7 +68,6 @@ int xc_altp2m_set_domain_state(xc_interface
> *handle,
> uint32_t dom, bool state)
> return rc;
> }
>
> -/* This is a bit odd to me that it acts on current.. */
> int xc_altp2m_set_vcpu_enable_notify(xc_interface *handle, uint32_t
> domid,
> uint32_t vcpuid, xen_pfn_t gfn)
> {
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 72c51faecb..49c3bbee94 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4533,8 +4533,7 @@ static int do_altp2m_op(
> return -EOPNOTSUPP;
> }
>
> -d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
> -rcu_lock_domain_by_any_id(a.domain) :
Re: [Xen-devel] [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer
>>> On 19.09.18 at 18:25, wrote: > And instead use NOW which is based on the TSC. This was already used > when running in shim mode, since there's likely no PIT in that > environment. > > Remove printing the CPU frequency, since it's already printed earlier > at boot, and getting the CPU frequency against the TSC without any > external reference timer is pointless. > > The motivation behind this change is to allow Xen to boot on HyperV > gen2 instances, which lack a PIT. > > Signed-off-by: Roger Pau Monné > --- > I'm not sure about the reason behind the usage of the PIT instead of > the TSC, maybe this was done because the TSC wasn't available until > the Pentium? Xen certainly doesn't care about such hardware anymore, > and the TSC is already used unconditionally in Xen. How good are the chances that on at least some hardware LAPIC and TSC frequencies derive from the same oscillator? If they do, you'd now basically calibrate a clock against itself, ... > Linux seems to prefer to calibrate the lapic timer against the PM > timer and has already dropped PIT usage for that. ... while this is almost certainly using a completely different timer, with the possible (hypothetical?) exception of SoC-s. Also, if we were to change the default against which clock to calibrate, I think we'd at least want to have a command line option controllable fallback to the current mode, just in case of unforeseen problems. This could be dropped a couple of releases later, if we really want to get rid of that code. > @@ -1176,10 +1117,6 @@ static int __init calibrate_APIC_clock(void) > > result = (tt1-tt2)*APIC_DIVISOR/LOOPS; > > -apic_printk(APIC_VERBOSE, ". CPU clock speed is %ld.%04ld MHz.\n", > -((long)(t2 - t1) / LOOPS) / (100 / HZ), > -((long)(t2 - t1) / LOOPS) % (100 / HZ)); > - I think I dislike this removal, despite the apparent redundancy, and in particular as part of an unrelated patch. It sitting next to > apic_printk(APIC_VERBOSE, ". host bus clock speed is %ld.%04ld > MHz.\n", > result / (100 / HZ), result % (100 / HZ)); is quite helpful imo, and APIC_VERBOSE mode is off by default anyway. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On 9/20/18 11:14 AM, Wei Liu wrote: >>> Reviewed-by: Tamas K Lengyel >> Are there any issues preventing this patch to go in? Possibly missing acks? > I don't think so, unless an explicit ack for the deletion of that > comment is required. In any case: > > Acked-by: Wei Liu > > I will commit this patch shortly. Thanks! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
